CVE-2026-71531
PrestaShop before 8.2.9 and 9.2.1 contains an authorization flaw in the Webservice API that allows an attacker holding a key restricted to o
CVSS
8.1
Alta
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 13 de nov. de 2026 · Última mod.: 13 de nov. de 2026 · CWE-863
Ainda não há histórico EPSS suficiente.
PrestaShop before 8.2.9 and 9.2.1 contains an authorization flaw in the Webservice API that allows an attacker holding a key restricted to one shop to act on data of every shop by submitting requests with id_shop=all or id_shop_group=N, which expand the shop context without validating the key's actual shop associations and cause shopHasRight() to evaluate the expanded set as a disjunction. Attackers can exploit this flaw via classes/webservice/WebserviceRequest.php to read, modify, or delete data belonging to shops they are not authorized for, including full customer records such as email addresses, secure_key, and password hashes across the installation.
- github.comhttps://github.com/PrestaShop/PrestaShop/releases/tag/8.2.9
- github.comhttps://github.com/PrestaShop/PrestaShop/releases/tag/9.2.1
- github.comhttps://github.com/PrestaShop/PrestaShop/security/advisories/GHSA-3f36-4qv4-vfgh
- www.vulncheck.comhttps://www.vulncheck.com/advisories/prestashop-webservice-api-authorization-bypass-via-id-shop-parameter
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-1240218.1 ALT—
———Control Web Panel (CWP) before webpanel_version 1.30.6 contains an authorization bypass vulnerability in the validate() function of api/v1/index.php that allows attackers holding a password-recovery token and a predictable legacy signature to obtain valid remote-API authorization without a proper API key. Attackers can exploit this flaw via the POST /cronjobsusers/ endpoint to add arbitrary cron commands and achieve command execution as the affected hosting account, and can also abuse the same token to access global account-list and account-detail routes exposing usernames, contact emails, and password hashes.3hCVE-2026-1281195.9 MÉD—
———SvelteKit is a framework for rapidly developing robust, performant web applications using Svelte. From version 2.60.1 until 3.1.1, applications using the experimental remote functions flag could assign the same generated identifier to separate non-exported query.batch functions. When those private functions shared a request batch, arguments intended for one function could be passed to another function, causing unexpected cross-function processing and possible disclosure of function arguments. This issue is fixed in 3.1.1.3hCVE-2026-1280882.2 BAI—
———russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to version 0.65.1, try_sign() captures an Arc<PrivateKey> before awaiting Agent::confirm() and does not revalidate the shared lock state or key presence after the await. This is a distinct residual defect in the remediation for CVE-2026-116794. A peer, including a remote SSH server using agent forwarding, can begin a confirmation-constrained signature request while the agent is unlocked and receive the signature after another connection locks the agent if the stale confirmation returns true. New post-lock requests are rejected and private key material is not disclosed, but the pending operation bypasses the current lock state. This issue is fixed in version 0.65.1.6hCVE-2026-1280873.7 BAI—
———russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From version 0.55.0 until version 0.65.1, the initial key exchange invokes client::Handler::kex_done() with the raw shared secret before check_server_key() accepts the server host key or certificate. A malicious SSH server can therefore trigger application-defined secondary-channel initialization or early data handling even when the server identity is subsequently rejected. Ordinary clients that keep the callback's no-op default or independently defer callback-derived actions until trust is confirmed are not affected. This issue is fixed in version 0.65.1.3hCVE-2026-1280776.5 MÉD—
———Nuxt is an open-source web development framework for Vue.js. From 4.6.0 until 4.6.4, Nuxt parses a request path beginning with // as a URL host before rendering a page, while Nitro server/middleware and routeRules continue to evaluate the original path. An unauthenticated request such as //x/admin can therefore resolve to the /admin page without route-scoped serverHandlers, server/middleware path checks, redirects, or security headers configured for /admin. API handlers in server/api and server/routes, appMiddleware, page middleware are unaffected. This issue is fixed in version 4.6.4.7hCVE-2026-1280716.5 MÉD—
———Nuxt is an open-source web development framework for Vue.js. Nuxt from 3.0.0 until 4.6.4, @nuxt/nitro-server from 3.20.0 until 4.6.4, and @nuxt/vite-server from 4.6.0 until 4.6.4, routeRules matching leaves an encoded slash (%2F) in the request path while a catch-all page such as app/pages/[...slug].vue or a custom multi-segment page route decodes it into a route parameter. The getRouteRules result is therefore incomplete, and an unauthenticated request can render the page without the redirect, headers, proxy, SSR, noScripts, appMiddleware, or appLayout rules configured for the decoded path. Protected content is resolved only when the page interprets the decoded parameter accordingly: a custom multi-segment parameter can contain the decoded path, while a repeatable catch-all must join the slash-containing array element; route.path remains encoded and does not resolve that resource. Static pages, single-segment parameters, server/api handlers, and server/routes handlers are not affected because they do not have the same encoded-path mismatch. This issue is fixed in version 4.6.4.7h