Suivez en temps réel les dernières failles de sécurité (CVE) identifiées mondialement. Données fournies par le National Vulnerability Database (NVD).
Ces informations proviennent directement du National Vulnerability Database (NVD).
DASEC GROUP vous accompagne dans la remédiation de ces failles.
Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. Reason: This candidate was issued in error. Notes: All references and descriptions in this candidate have been removed to prevent accidental usage.
Ekia File Manager 1.2.7 exposes com.ekia.filecontrolmanager.OpenFileProvider as an exported Android ContentProvider without requiring caller permissions. The provider maps the caller-controlled URI path directly to a filesystem path and passes it to new File(...). It then supports query(), openFile(), and delete() operations. Because the provider is exported and lacks android:permission, android:readPermission, or android:writePermission, another local application can access the provider authority and cause File Manager's process to read, create, overwrite, or delete files that are accessible to that process.
Yayson is a library for serializing and reading JSON API data in JavaScript. Prior to 4.3.0, Store and LegacyStore use attacker-controlled JSON:API type, id, and relationship names as keys in plain-object lookup tables in src/yayson/store.ts and src/yayson/legacy-store.ts. A document whose type is __proto__ causes model-cache writes to modify Object.prototype, with the attacker controlling the polluted property name through id and its value through attributes. The malicious type can also be supplied by an included resource, and LegacyStore is reachable when a configured types mapping resolves to __proto__. Unsafe relationship names including __proto__, constructor, and prototype provide additional document-derived member paths. The resulting process-wide prototype pollution can cause denial of service and logic corruption; authorization bypass or code execution depends on suitable gadgets in the consuming application. This issue is fixed in version 4.3.0.
PraisonAI is a multi-agent teams system. Prior to 4.6.62, src/praisonai/praisonai/tools/multiedit.py passes the LLM-controlled filepath parameter directly to open for reading and writing without traversal rejection, symlink resolution, a workspace boundary, or protected-path checks. Prompt-influenced agents can read files through edit and diff behavior or overwrite files accessible to the process, exposing secrets and enabling persistence or application tampering. This issue is fixed in 4.6.62.
PraisonAI is a multi-agent teams system. Prior to 4.6.62, setting PRAISONAI_CALL_AUTH to disabled makes verify_token accept requests to /api/v1/agents/{id}/invoke without CALL_SERVER_TOKEN authentication. Deployments that use the application's advertised opt-out can expose registered agents and their connected tools or private context to unauthenticated invocation. The vulnerability is fixed in 4.6.62.
PraisonAI is a multi-agent teams system. Prior to 4.6.58, praisonai.jobs.server.create_app mounts praisonai.jobs.router.create_router under /api/v1/runs without authentication or per-job authorization. Network clients can submit attacker-controlled prompts and agent configuration, list and read jobs, stream results, and cancel or delete other jobs, exposing service credentials and connected tool capabilities to unauthorized agent execution. This vulnerability is fixed in 4.6.58.
PraisonAI is a multi-agent teams system. Prior to 4.6.58, recipe serve installs APIKeyAuthMiddleware or JWTAuthMiddleware when an operator selects api-key or JWT authentication, but each middleware forwards requests when PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET and the corresponding recipe value are absent. Unauthenticated clients can then reach recipe execution, input, and output surfaces and may trigger connected tools despite the operator explicitly enabling authentication. This issue is fixed in 4.6.58.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the default UI host applications expose POST /api/mcp/connect without mandatory authentication and accept caller-controlled command and args values that PraisonAIUI passes to StdioMCPClient to start a local process. Because the UI commands bind to 0.0.0.0 by default, a reachable unauthenticated client can execute commands as the UI service account even when the MCP handshake later fails. This vulnerability is fixed in 4.6.59.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the WhatsApp and Linear bot webhook handlers verify HMAC signatures only when WHATSAPP_APP_SECRET or LINEAR_WEBHOOK_SECRET is configured and otherwise parse and dispatch unsigned request bodies. A remote unauthenticated client that reaches the webhook route can forge messages, comments, or agent-session events, impersonate platform users, influence agent prompts and actions, and disrupt bot processing. This issue is fixed in 4.6.59.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the unauthenticated Jobs API accepts an absolute or traversing agent_file path in POST /api/v1/runs and passes it to the job executor without a workspace allowlist or boundary check. A remote caller can cause the server to open files accessible to the service account, exposing credentials, keys, environment variables, and other local data. This vulnerability is fixed in 4.6.59.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.
Craft Commerce is an ecommerce platform for Craft CMS. From 4.0.0 until 4.11.2 and 5.6.5, CartController in src/controllers/CartController.php activates its RateLimiter only when the number POST or GET parameter is supplied. An unauthenticated attacker can submit couponCode values to actionUpdateCart for the session-based cart while omitting number, preventing creation of the IP rate-limit identity and allowing unlimited automated coupon-code guessing and enumeration. This issue is fixed in versions 4.11.2 and 5.6.5.
langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, the langgraph-api run-creation path authorizes the assistant attached to a run by dispatching assistants.search with an incomplete value instead of the assistants.read event used by direct reads and cron creation. In deployments with custom resource handlers that register only assistants.read, omit an assistants.search handler, and have no global fallback handler, no applicable handler supplies an owner filter, allowing a low-privileged user to reference another user's private assistant through POST /runs or POST /threads/{thread_id}/runs. The run-creation response can disclose the private assistant's metadata, config, and context, and the run can execute using that assistant's configuration. Deployments without custom authorization handlers, or with an equivalent owner filter applied through a global handler or across all assistant events, are not affected. This issue is fixed in version 0.10.0.
langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, langgraph-api permits a run or cron to specify a relative webhook target that is delivered through an in-process loopback transport, and the authentication middleware treats that transport as internal without applying the authentication context used for external requests. In deployments that rely on per-user authorization to separate threads and runs, an authenticated user can direct a webhook to the server's own thread and run routes, allowing creation of a run on or modification of another user's thread and limited incorporation of the targeted thread's metadata into the created run record. The affected path requires webhook targets and per-user authorization boundaries; deployments that deliberately re-enable loopback delivery should restrict it to controlled same-process routes because those webhooks remain unauthenticated. This issue is fixed in version 0.10.0.
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to 1.6.0, a malicious state-sync peer can crash a syncing node by sending a crafted TrieChunk whose proof contains a TrieNodeChild suffix that is individually valid but exceeds the 63-byte KeyNibbles backing array when combined with the parent key. KeyNibbles::Add in primitives/src/key_nibbles.rs performs the combined slice operation without checking the total length, and the input reaches put_chunk, TrieNodeChild::key, and TrieNodeChild::is_stump before proof.verify, so the attacker does not need a valid cryptographic proof. Exploitation requires the attacker to be selected as the victim's sync peer during state sync. The resulting out-of-bounds panic is transient because the node restarts and resynchronizes. This issue is fixed in version 1.6.0.
