CVE Watch3 de nov. de 2026

CVE-2026-55186

Silverstripe MFA provides multi-factor authentication for Silverstripe CMS. Prior to 6.0.0, the CMS 5 password reset flow can issue a logged

CVSS

4.2

Média

EPSS

0.3%

p20

KEV

—

Exploit Today

0-100

Publicado: 3 de nov. de 2026 · Última mod.: 3 de nov. de 2026 · CWE-288

EPSS · 30d

0.3%EPSS · 30 dias0.3%

2026-11-042026-11-05

Descrição técnica

Silverstripe MFA provides multi-factor authentication for Silverstripe CMS. Prior to 6.0.0, the CMS 5 password reset flow can issue a logged-in session after a user changes a password but before the user's configured multi-factor authentication challenge is completed. An attacker with access to the user's email account can follow the reset flow and bypass the additional authentication factor. CMS 6 is not affected. This issue is fixed in version 6.0.0.

Referências oficiais

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-123746—

—

———The Symfony Security HTTP component AuthenticatorManager::authenticateUser() does not run the firewall user checker’s checkPostAuth() method when a user is authenticated programmatically, allowing an account rejected by a custom user checker, such as an expired account, to be authenticated in Symfony versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11. AuthenticatorManager::authenticateUser() is used by UserAuthenticatorInterface::authenticateUser() and by the SecurityBundle’s Security::login() to authenticate a user programmatically, but it does not dispatch the security.authentication.success event, on which checkPostAuth() runs. The fix for CVE-2024-50341 made Security::login() call checkPreAuth(), but checkPostAuth() was still skipped. As a result, an account rejected by a custom user checker in checkPostAuth() is refused by form login and the other authenticators of the firewall, but can still be authenticated programmatically. Applications are affected when they use a custom user checker that rejects users in checkPostAuth() and authenticate users programmatically, for example after a password reset or an e-mail verification link. A user whose account is rejected can then obtain an authenticated session through that flow. The default user checker does nothing in checkPostAuth(), so the default configuration is not affected. The fix makes AuthenticatorManager::authenticateUser() dispatch the security.authentication.success event once the token is created and before it is stored, as authentications through the firewall do, so that checkPostAuth() runs and can reject the user.7h CVE-2026-493938.4 ALT

—

——0OpenHuman is an open-source agent harness available as a desktop application and Rust library. Before 0.56.0, the core server protects HTTP POST requests to /rpc with bearer middleware but exposes Socket.IO rpc:request and chat:start handlers without equivalent transport or handler-level authentication. A local unauthenticated client can connect to the Socket.IO namespace and dispatch requests through the same protected controller path that rejects a missing bearer on /rpc. Depending on the selected method, the attacker can read configuration or health data, start agent flows, interact with integrated account APIs, alter local data, or stop and restart services. This issue is fixed in version 0.56.0.1d CVE-2026-73578—

—

——0Missing authorization enforcement in RequestHandler.renderView in Apache OFBiz 24.09 before 24.09.08 on all platforms allows a remote unauthenticated attacker to bypass the request-map authentication policy for protected views by supplying a crafted _LAST_VIEW_NAME_ value, which is stored as saved-view state in the anonymous session and later rendered without re-applying the original view's authentication requirement, potentially exposing protected views and associated business data. Users are recommended to upgrade to version 24.09.08, which fixes this issue.1d CVE-2026-73577—

—

——0Incorrect authorization in RequestHandler in Apache OFBiz 24.09 before 24.09.08 on all platforms allows a remote unauthenticated attacker to bypass the authentication requirement of a protected view by appending it as a path suffix to a public request (e.g., /catalog/control/ListLocales/showPortalPage), causing the servlet to authorize the request based on the public path component while rendering the protected suffix view. Users are recommended to upgrade to version 24.09.08, which fixes this issue.1d CVE-2026-52848—

31.1%

——9GLPI is a free asset and IT management software package. From 11.0.0 until 11.0.8, during the login phase, an unauthenticated user could use a crafted URL to skip one-time-password verification, defeating two-factor authentication. This issue is fixed in version 11.0.8.2d CVE-2026-1042037.5 ALT

56.7%

——17Traccar is an open source GPS tracking system. From 5.1 until 6.15.0, WebModule.java's MediaFilter Guice mapping and WebServer.java's Jetty ResourceServlet assign different routing meanings to path parameters at /api/media/*. An unauthenticated attacker who knows or guesses a device unique ID and media filename can insert a semicolon at the Servlet boundary, bypass MediaFilter's session and device authorization checks, and retrieve the protected media because Jetty still dispatches the noncanonical path to ResourceServlet. The demonstrated impact is read-only disclosure of a protected device media file; depending on the deployment and stored media, this could expose photographs, audio, video, or other uploaded files. The advisory does not establish directory listing, traversal, modification, account takeover, denial of service, or code execution. Reverse proxies that reject or rewrite semicolon path parameters may block the request. This issue is fixed in version 6.15.0.2d