Authentication Bypass
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
How It Works
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications. Instead of cracking passwords through brute force, attackers manipulate the authentication process itself to gain unauthorized entry. This typically occurs through one of several pathways: exploiting hardcoded credentials embedded in source code or configuration files, manipulating parameters in authentication requests to skip verification steps, or leveraging broken session management that fails to properly validate user identity.
The attack flow often begins with reconnaissance to identify authentication endpoints and their underlying logic. Attackers may probe for default administrative credentials that were never changed, test whether certain URL paths bypass login requirements entirely, or intercept and modify authentication tokens to escalate privileges. In multi-step authentication processes, flaws in state management can allow attackers to complete only partial verification steps while still gaining full access.
More sophisticated variants exploit single sign-on (SSO) or OAuth implementations where misconfigurations in trust relationships allow attackers to forge authentication assertions. Parameter tampering—such as changing a "role=user" field to "role=admin" in a request—can trick poorly designed systems into granting elevated access without proper verification.
Impact
- Complete account takeover — attackers gain full control of user accounts, including administrative accounts, without knowing legitimate credentials
- Unauthorized data access — ability to view, modify, or exfiltrate sensitive information including customer data, financial records, and intellectual property
- System-wide compromise — admin-level access enables installation of backdoors, modification of security controls, and complete infrastructure takeover
- Lateral movement — bypassed authentication provides a foothold for moving deeper into networks and accessing additional systems
- Compliance violations — unauthorized access triggers breach notification requirements and regulatory penalties
Real-World Examples
CrushFTP suffered a critical authentication bypass allowing attackers to access file-sharing functionality without any credentials. The vulnerability enabled direct server-side template injection, leading to remote code execution on affected systems. Attackers actively exploited this in the wild to establish persistent access to enterprise file servers.
Palo Alto's Expedition migration tool contained a flaw permitting attackers to reset administrative credentials without authentication. This allowed complete takeover of the migration environment, potentially exposing network configurations and security policies being transferred between systems.
SolarWinds Web Help Desk (CVE-2024-28987) shipped with hardcoded internal credentials that could not be changed through normal administrative functions. Attackers discovering these credentials gained full administrative access to helpdesk systems containing sensitive organizational information and user data.
Mitigation
- Implement multi-factor authentication (MFA) — requires attackers to compromise additional verification factors beyond bypassed primary authentication
- Eliminate hardcoded credentials — use secure credential management systems and rotate all default credentials during deployment
- Enforce authentication on all endpoints — verify every request requires valid authentication; no "hidden" administrative paths should exist
- Implement proper session management — use cryptographically secure session tokens, validate on server-side, enforce timeout policies
- Apply principle of least privilege — limit damage by ensuring even authenticated users only access necessary resources
- Regular security testing — conduct penetration testing specifically targeting authentication logic and flows
Recent CVEs (42440)
Local privilege escalation in hMailServer 6.0.0 through 6.3.5 on Windows allows an authenticated local user-one with an interactive logon but no hMailServer credentials-to abuse COM objects to read and write arbitrary files as the service account and send mail as any sender. The service registers its COM classes without DCOM launch or access permissions and calls CoInitializeSecurity with a null security descriptor, so any user logged on at the console or over Remote Desktop can activate hMailServer.Message, Attachments, and hMailServer.FetchAccount objects. If the service runs as LocalSystem (the default), arbitrary file write can lead to code execution as SYSTEM; no public exploit identified at time of analysis.
Local credential theft in Brocade ASCG before 3.5.0 allows a low-privileged authenticated user on the ASCG VM to extract stored management credentials for onboarded SANnav instances by issuing requests into the SANnav host network namespace, enabling follow-on compromise of connected Brocade SANnav servers or managed Fibre Channel switches. The vulnerability is CWE-522 (insufficiently protected credentials) and requires an existing local foothold (CVSS vector AV:L/PR:L, no user interaction), so unauthenticated remote attackers cannot exploit it directly. No public exploit identified at time of analysis.
Unauthenticated attackers with adjacent-network reachability can push an unauthorized Certificate Authority certificate into the TLS client trust store of Brocade ASCG (all versions before 3.5.0), because the product's management interface accepts CA certificates without authentication. A successful injection lets an on-path adversary Man-in-the-Middle the outbound TLS connections ASCG establishes to the managed Fibre Channel switches and peer nodes it administers, producing high confidentiality and integrity impact (CVSS 7.6; CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N; independent CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N). Because the vector is PR:N the certificate submission is unauthenticated, but exploitation still requires the attacker to be logically adjacent to the management plane (AV:A) and, for the MITM payoff, to hold an on-path position between ASCG and its outbound peers (AT:P) - no public exploit code and no CISA KEV entry were identified at time of analysis, so this is a genuine but moderate-priority issue rather than an urgent emergency.
Authentication bypass in Brocade ASCG versions prior to 3.5.0 allows unauthenticated attackers on an adjacent network to fully compromise the SupportLink API component due to a hard-coded cryptographic key (CWE-321) shared across all deployments. Exploitation requires adjacent network access and recovery of the key, but no public exploit code has been identified at time of analysis. The vendor has released version 3.5.0 to address the flaw.
Unauthenticated API access in Brocade ASCG (Active Support Connectivity Gateway) before version 3.5.0 lets an attacker on an adjacent network perform privileged administrative actions - reading sensitive system configuration mapping data, modifying managed device inventories, and changing operational settings - without presenting any credentials. The flaw is scored CVSS 8.7 (CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L) and is rooted in CWE-306, a missing authentication check for a critical function; no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing). The dominant constraint is reachability rather than skill: the attacker must be able to route to the ASCG administrative management/API interface from an adjacent or logically local segment, so deployments that place the appliance behind segmentation or firewalls are materially less exposed.
Local privilege escalation in Brocade Active Support Connectivity Gateway (ASCG) before 3.5.0 stems from a well-known Brocade default password embedded in a script that is distributed to every customer, allowing any local authenticated user with read access to the installation path to recover the credential and elevate privileges on Open Virtual Appliance (OVA) deployments where default configuration settings remain in place. The flaw is rated 7.0 (High) under CVSS 4.0 with a local vector (AV:L, PR:L, UI:P), meaning an attacker must already hold a low-privilege local account and passive user interaction is required, so it is not remotely reachable. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the realistic risk is concentrated on OVA deployments that have not rotated the default credential.
Missing authentication in the Brocade ASCG data collector API endpoint allows an unauthenticated adjacent-network attacker to instruct the appliance to establish SSH connections to arbitrary hosts and execute arbitrary system commands, effectively turning it into a proxy or execution vector. Affected versions are those before 3.5.0; the vulnerability has a CVSS 4.0 score of 8.6 (AV:A/PR:N/UI:N) but requires network reachability to the service, and no public exploit identified at time of analysis.
Brocade Active Support Connectivity Gateway (ASCG) builds prior to 3.5.0 embed a static cryptographic key inside shipped software binaries, so an attacker who already holds high-privilege local access to the appliance or obtains the binaries can extract that key and use it to decrypt management credentials stored at rest or to forge administrative synchronization messages that peer nodes accept. The vendor scores this High at CVSS 4.0 8.4 (AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H), and the independent assessment concurs with a CVSS 3.1 base of AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H: the vector requires authenticated, high-privileged local access, so this is not a network-facing, unauthenticated path. No public exploit code has been identified and the flaw is not in CISA KEV, but the use of a single shared key across installations means any successful extraction has cross-deployment consequences; upgrading to ASCG 3.5.0 or later removes the condition.
Authentication bypass in the Ultimate Multisite WordPress plugin before 2.17.0 lets an unauthenticated remote attacker (CVSS PR:N) log in as any existing WordPress account, including a Network Super Admin, whose email address they know - but only on sites whose checkout form is configured without a password field and only when the target account has no existing Ultimate Multisite customer record. The root cause is that the plugin's duplicate-account check normalizes the submitted email address differently from the lookup used to create the customer, so a logged-out checkout silently links to and authenticates as the matching existing WordPress user. The 2.15.1 fix for CVE-2026-75957 does not remediate this bypass; vendor-released patch 2.17.0 is available, and no public exploit code has been identified at time of analysis (no CISA KEV entry). Vendor CVSS is 9.8, though our independent assessment applies AC:H (8.1) because both the password-less checkout configuration and the absence of a pre-existing customer record are required.
Unauthenticated control-plane takeover in the Brocade Active Support Connectivity Gateway (ASCG) HTTPS service allows a network-adjacent attacker to issue control commands, alter cluster state, and modify system configuration in every release before 3.5.0. The defect is a plain missing-authentication condition (CWE-306): no credentials, tokens, or user interaction are involved, and no non-default configuration is required, since the HTTPS control interface simply does not enforce authentication or access control on incoming requests. The principal limiting factor is reachability rather than exploit complexity - the vendor scores it CVSS 4.0 8.7 with AV:A/PR:N/UI:N (adjacent, unauthenticated, no user interaction), so the attacker must already have a foothold on the appliance's management or local network segment. No public exploit code has been identified and the issue is not listed in CISA KEV at time of analysis, so urgency is driven by how widely the management interface is exposed on flat or loosely segmented networks.
Authentication bypass in Brocade Fabric OS versions before 9.2.2d running on the MXG610 extension switch lets a network-adjacent attacker reach an unprotected endpoint in the web management interface's Single Sign-On workflow and obtain administrative access to the device. No credentials or user interaction are required (PR:N/UI:N), although High attack complexity (AC:H) means conditions outside the attacker's control must line up for reliable exploitation, and exposure is confined to MXG610 deployments with a reachable management interface. No public exploit code has been identified at the time of analysis, and there is no confirmation of active exploitation.
Authentication bypass in Brocade Fabric OS 9.2.2d and 10.0.0 through 10.0.0a1 allows a local low-privileged process to forge IPC storage callbacks and register an administrative web-management session without legitimate authentication. The flaw is CWE-306 (missing authentication for a critical function) and has a high severity score (CVSS 8.5, v4.0 AV:L/PR:L), but exploitation requires an existing local foothold on the switch rather than network access. No public exploit or KEV confirmation was identified at time of analysis.
Privilege escalation and command injection in the inter-switch remote execution service of Brocade Fabric OS let an attacker who already holds high privileges on one fabric-joined switch bypass authentication checks on the receiving switch and execute arbitrary root commands, either locally or on other managed fabric members where remote command execution is enabled. Affected releases are Fabric OS versions before 9.2.2d and 10.0.0 through 10.0.0a1; switches running 9.2.2d or later are not affected. Exploitation is access-gated rather than mass-exploitable: it requires an existing high-privilege foothold on a switch already joined to the target fabric and the inter-switch remote execution feature to be enabled on the receiving members, and no public exploit has been identified at time of analysis (no CISA KEV listing).
An authenticated, low-privileged user in one Virtual Fabric on a Brocade Fabric OS switch can submit a request carrying an arbitrary fabric identifier that is never validated against the caller's authorization scope, allowing unauthorized cross-fabric operations and disclosure of configuration details belonging to tenants or Virtual Fabrics they were not granted access to. Affected builds are Fabric OS releases before 9.2.2d and 10.0.0 through 10.0.0a1, and exploitation requires an adjacent/management-network position (AV:A) plus valid credentials (PR:L) in an environment where multiple tenants actually share the switch; single-fabric deployments with no tenant separation offer nothing to cross into. Impact is confined to confidentiality and integrity of other fabrics' configuration with no availability effect, and there is no public exploit identified at time of analysis and no CISA KEV listing.
Brocade Fabric OS Management Server before version 10.0.1 can be manipulated by a compromised or rogue Fibre Channel switch that is already trusted within the fabric, which uses crafted inband vendor-unique Common Transport (CT) management requests to bypass administrative authentication. This lets the unauthorized peer perform sensitive administrative actions on the target device, including resetting administrative passwords, rebooting the system, and initiating firmware downloads. The attack is confined to the Fibre Channel fabric and cannot be launched from the management IP network or the internet; it requires a pre-compromised fabric peer (assessed AV:A/AC:H with an AT:P precondition in the vendor vector), and no public exploit code has been identified at time of analysis.
Authenticated non-admin users of Apache DolphinScheduler 3.2.0 up to (but not including) 3.4.3 can retrieve the Kubernetes kubeconfig that administrators stored for cluster integration, because the API that serves that data performs no authorization check (CWE-862). With the disclosed kubeconfig an attacker can authenticate directly to the Kubernetes API from outside DolphinScheduler, and the real-world severity is bounded by whatever privileges the embedded service account holds - cluster-admin-grade credentials expose Kubernetes Secrets and allow pod creation and persistence, while narrowly scoped credentials sharply limit what is achievable. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the issue is unreachable on deployments that never configured Kubernetes cluster integration or where the requester cannot obtain even a low-privileged account.
Broken authorization in Apache DolphinScheduler before 3.4.3 allows any authenticated user to retrieve connection details - including stored data source passwords - for data sources they are not authorized to access via the /unauth-datasource and /authed-datasource endpoints. Exploitation is network-reachable (AV:N), low complexity (AC:L), requires no user interaction (UI:N) and only a valid low-privileged account (PR:L), yielding high confidentiality impact (C:H) with no integrity or availability impact per our assessment; NVD/vendor scoring differs slightly by also crediting low integrity impact (I:L). Because the leaked credentials can be reused against the underlying databases, the practical consequence extends beyond information disclosure to potential downstream database compromise; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor-released fix is version 3.4.3.
Authenticated users of Apache DolphinScheduler can stop or create savepoints for task instances belonging to projects they are not authorized to access, because the project-scoped task-instance API fails to enforce per-project authorization. The issue affects all releases before 3.4.3 and is reachable over the network via the /dolphinscheduler/projects/{projectCode}/task-instances/{taskInstanceId}/stop and /savepoint endpoints. The independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L (the vendor-published score is 8.1), meaning a valid authenticated account plus knowledge or enumeration of a target task instance ID is required - anonymous exploitation is not possible - and the practical impact is an integrity and limited availability concern in multi-tenant or multi-project deployments where project isolation is a security boundary; no public exploit code has been identified at time of analysis, EPSS is a low 0.16% (5th percentile), and the CVE is not in CISA KEV. This is a genuine but moderate-priority issue rather than a top-tier emergency.
Authorization bypass in Apache DolphinScheduler before 3.4.3 allows an authenticated user to alter task definitions, together with their upstream dependencies, in projects they are not authorized to access. The attacker pairs a projectCode they legitimately belong to with a task-definition code belonging to a different project when calling the /dolphinscheduler/projects/{projectCode}/task-definition/{code}/with-upstream endpoint, because the handler never confirms that the task code actually belongs to the supplied project. Impact is confined to integrity and availability of workflow definitions (assessed vector I:H/A:L, C:N), so unauthorized projects may have their pipelines silently rewritten or disrupted; no public exploit code has been identified at time of analysis and EPSS is only 0.18% (7th percentile), making this a genuine but moderate-priority issue rather than an urgent emergency.
Incorrect authorization in Octopus Server causes the platform to evaluate multiple scoped permission assignments incorrectly, so an already-authenticated, highly privileged user can accumulate deployment permissions beyond those actually granted to them. This is an authenticated (PR:L) network-reachable flaw requiring a valid Octopus account that already holds scoped permission assignments; the realistic threat actor is a malicious insider or an attacker using a compromised legitimate account rather than an anonymous internet attacker, and no victim interaction is needed. With C:H/I:H/A:H, successful abuse can alter and deploy code across environments the user was never authorized to touch. There is no CISA KEV listing and no public exploit code identified at time of analysis, though the 8.7 CVSS severity and default multi-scope evaluation behavior make it a priority for organizations relying on Octopus scoping for separation of duties.
Unauthenticated remote command execution in Splunk Enterprise search head cluster members allows any network-reachable attacker to run operating-system commands as the Splunk service account. The flaw (CWE-306) is that the Patroni REST API exposed on a search head cluster member performs critical configuration operations without requiring authentication, so an attacker who can reach that interface can invoke it directly - no credentials needed. Only deployments running search head clustering on Splunk Enterprise versions below 10.4.3 or below 10.2.7 are exposed; 10.0.x and 9.4.x are explicitly unaffected. CVSS 3.1 base 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) reflects a maximum-severity, low-complexity path with full confidentiality, integrity and availability impact, and no public exploit code or confirmed active exploitation has been identified at time of analysis, so exposure is driven mainly by whether the Patroni REST API port is reachable from untrusted networks.
Missing authorization in the WPMU DEV Forminator WordPress plugin (all versions through 1.57.2) allows unauthenticated remote attackers to perform privileged actions that should require an access-control check, altering site data with a high integrity impact (CVSS 7.5, AV:N/AC:L/PR:N/UI:N). Because the vector carries PR:N and UI:N, exploitation requires only that a vulnerable Forminator installation be network-reachable; no credentials or victim interaction are needed, though the impact is confined to integrity with no confidentiality or availability loss. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV), making this a moderate-priority, broadly-reachable issue rather than an emergency.
Improper access control in Cisco Meraki firmware - spanning MR wireless access point software, MX security appliance firmware, MV camera firmware, and Cisco Campus Gateway Software - lets an attacker positioned on an adjacent Layer 2 or wireless segment bypass authentication and reach protected functionality, with the highest impact on confidentiality. No credentials (PR:N) and no user interaction (UI:N) are required, attack complexity is low, and the Cisco-assigned score is 8.8 because the flaw crosses a security boundary (S:C); however, the attack is not routable from the internet, so real-world exposure is limited to whoever already shares a segment with the device, and no public exploit code or confirmed active exploitation was identified at time of analysis. Cisco addressed the issue in a proactive internal hardening release and published advisory cisco-sa-hardening-meraki-os-drbEX9GH, which should be used to confirm exact affected firmware versions because the advisory bundles several internally discovered issues.
Unauthenticated remote access-control bypass in Cisco APIC gives network-reachable attackers full compromise of confidentiality, integrity, and availability (CVSS 9.8) against the ACI data-center controller. The CVE groups multiple internally discovered improper access control issues (CWE-284) addressed by Cisco hardening releases, and the provided data does not enumerate exact affected versions, so the Cisco advisory must be used to confirm vulnerable releases. No public exploit identified at time of analysis; the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms the flaw is remotely reachable without authentication or user interaction, though real-world exposure depends on reachability to APIC's typically isolated management/API plane.
Missing authentication for critical functions in Cisco License On-Prem (formerly Cisco Smart Software Manager On-Prem, SSM On-Prem) lets unauthenticated remote attackers reach protected functionality with no credentials and no user interaction, exposing confidentiality, integrity, and availability (CVSS 9.8, AV:N/AC:L/PR:N/UI:N). The issues were discovered during Cisco's own internal security review and are bundled into a hardening release documented in Cisco advisory cisco-sa-hardening-ssm-Ph77wdhf rather than being tied to a single feature or endpoint. No public exploit code and no confirmed active exploitation have been identified at time of analysis, but because the licensing server is frequently deployed on internal networks with broad reach to managed devices and license data, any internet- or flat-network-exposed instance should be treated as an urgent patch priority.
Improper access control in Cisco NX-OS - including NX-OS running in ACI mode and the NX-OS component of managed Cisco Unified Computing System deployments - could allow a remote, unauthenticated attacker to bypass access restrictions and achieve full compromise of confidentiality, integrity, and availability (CVSS 3.1 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The issue was identified during a Cisco internal security review and is addressed in a NX-OS software hardening release rather than a single-point bug fix, with the advisory grouping multiple internally discovered access-control weaknesses under CVE-2026-76455. At time of analysis no public exploit code or confirmed active exploitation has been identified, and the specific vulnerable feature, protocol, or configuration mode is not disclosed in the available data, so exposure must be validated against the Cisco advisory before triage.
SQL injection in the Homer coordinator's POST /api/v4/statistics/query endpoint allows a remote attacker to execute arbitrary DuckDB SQL against the FlightSQL backend, exposing or altering all stored VoIP call records, SIP messages and metadata. The V4StatisticsQuery handler forwards the caller-supplied rawquery field verbatim to DuckDB without the sqlvalidator.ValidateRawSQL() neutralization applied in sibling handlers, so any authenticated user is sufficient (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1); the vendor notes that on default deployments an empty JWT secret collapses this to pre-authentication reachability. Publicly available exploit code exists (the advisory ships a working curl PoC, and DuckDB INSTALL/LOAD is reachable for extension-based exfiltration); no confirmed active exploitation (CISA KEV) has been recorded at time of analysis.
Unauthenticated remote attackers can reset the password of any account, including administrative users, in Cisco License On-Prem (formerly Cisco Smart Software Manager On-Prem) by exploiting improper authorization checks in the web-based password-reset function, leading to full application compromise. The flaw has a CVSS score of 9.1 (AV:N/AC:L/PR:N/UI:N) and requires only network reachability to the management interface; no public exploit has been identified at time of analysis. Deployments exposing the interface to untrusted networks are at highest risk, while well-segmented instances are materially harder to attack.
Homer (sipcapture/homer-app) deployments running in the default internal authentication mode bootstrap an administrator account with the hardcoded credentials admin / sipcapture and never force a password change, so any unauthenticated attacker who can reach the /api/v3/auth login endpoint can obtain a full admin JWT on a freshly deployed instance. The GitHub advisory publishes working exploit code (a two-request curl sequence against /api/v3/auth and /api/v3/users), and no lockout, rate limiting, or first-login change requirement is in place, making publicly available exploit code exist for this CWE-798 hardcoded-credential flaw. Vendor fixes ship in Homer 11.0.283 (commit b2e942031ff8cd7435a244ebef306ee97d16b809), which replaces the fixed bootstrap hash with a random password logged once at startup or an operator-supplied admin_password_hash.
Missing authentication in the HOMER (sipcapture Homer) coordinator allows remote unauthenticated attackers to fully control the administrative API whenever the JWT signing secret is left at its default empty value. Because JWTMiddleware and JWTMiddlewareV4 both short-circuit with next(c) when the secret is empty - and the middleware is not even registered on the protected route groups in that state - every endpoint under /api/v1, /api/v3 and /api/v4 is reachable without credentials, permitting reads and writes of users, configuration, database connection strings and stored VoIP call data, including creation of a new admin user. The flaw carries a 9.8 CVSS (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) under CWE-306, is unauthenticated by vector, and a vendor fix is available per the advisory; exploitation status is no public exploit identified at time of analysis, though the vendor advisory itself contains curl-based reproduction steps.
ImageMagick's CUT image decoder fails to enforce the configured security policy (policy.xml) when it derives and opens the companion '.PAL' palette file next to a processed CUT image, so an unauthenticated remote attacker who can get a crafted CUT file into an image-processing pipeline can read a palette file that policy explicitly denies and can also crash the process. All releases before 7.1.2-31 (including the entire 7.0.0 line) and before 6.9.13-56 are affected; the flaw is only meaningful when a restrictive read policy is actually in place, since the practical impact is limited to policy bypass for one adjacent file plus a denial-of-service crash, with no write or code-execution capability. Advisory GHSA-r868-pmwh-fv2c has been published with upstream commits and fixed release tags, EPSS is low at 0.12% (2nd percentile), and CISA's SSVC assessment rates exploitation as none and automatable as no, so no public exploit code has been identified at time of analysis.
ImageMagick before 7.1.2-31 and 6.9.13-56 resolves image coders before applying its security-policy authorization check, so a crafted image can invoke a coder that a policy.xml rule with domain='coder' was meant to block and read data the policy prohibits. Real exposure is much narrower than the CVSS 7.5 network vector implies: the flaw is only meaningful where an administrator has actually configured a coder-domain policy (installations without one have no control to bypass), and the target application must still parse attacker-supplied images. With EPSS at 0.14% (3rd percentile), SSVC exploitation rated none, and no public exploit or CISA KEV activity identified at time of analysis, this is a low-urgency hardening item rather than an emergency.
Insecure direct object reference (IDOR) in Gophish through 0.12.1 lets any authenticated, low-privileged user take over other users' groups, templates, landing pages, and sending profiles by supplying a victim's sequential object ID to the API create endpoints (/api/groups/, /api/templates/, /api/pages/, /api/smtp/). Because the server trusts the client-supplied ID instead of assigning a new one, the attacker can overwrite and reassign the victim's objects, locking the original owner out and exposing their recipient lists. Exploitation requires a valid account on a multi-user deployment (a single-operator install has no victims to hijack), and publicly available exploit code exists; there is no confirmed in-the-wild exploitation (CISA KEV) and no vendor patch was identified at time of analysis.
LMCache through 0.5.5 ships a multiprocess-mode HTTP management/internal API server that binds to all network interfaces by default with no authentication, letting remote unauthenticated attackers reach management endpoints that should never be exposed. An attacker who can reach the management port can read process environment credentials via GET /env, read configuration via GET /config, clear or delete cached objects, and modify tenant quotas so that other tenants' cached data is evicted. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV), but exploitation requires only that LMCache runs in multiprocess mode and that the management port is network-reachable, so exposure is bounded mainly by network segmentation rather than by any authentication or user-interaction barrier (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/C:H/I:L/A:H).
Remote unauthenticated attackers can disrupt and manipulate LMCache's multiprocess coordinator fleet control API in default deployments through 0.5.5, using the /instances, /quota, /events, and /directory/keys endpoints to deregister instances, overwrite quotas, inject events, and disclose placement metadata. The independent assessment confirms that the only material barrier is network reachability because the API binds to all interfaces with no authentication (PR:N) and no user interaction, resulting in low confidentiality and integrity impact and high availability impact. No public exploit identified at time of analysis and no CISA KEV entry was present, but this is a genuine, actionable priority rather than an inflated CVSS score.
Unauthenticated remote code execution in LMCache through 0.5.5 allows network-reachable attackers to execute arbitrary Python and operating-system commands as the LMCache process by posting scripts to the /run_script endpoint; the endpoint's existing __import__ guard is bypassed via the injected FastAPI app object, which exposes real builtins (CWE-306, CVSS 9.3 v4.0 / 3.1 AV:N/AC:L/PR:N/UI:N). No public exploit code or confirmed in-the-wild activity has been identified at time of analysis, though the vulnerability details and vendor advisory are public. The primary limiting factor is deployment exposure: exploitation requires the internal API HTTP server to be enabled and bound to a network-accessible interface rather than restricted to localhost or a trusted management network.
Unauthenticated account takeover in Sungrow iSolarCloud is achievable by sending a login request to the platform's API with "login_type":"5" and the victim's email address in the user_account property, letting an attacker assume control of an arbitrary account without valid credentials. The affected range is stated as iSolarCloud builds 'before 2026' (CPE is a wildcard, so no exact fixed build is published), and because iSolarCloud is the control plane for grid-connected PV and battery-storage fleets, the assessed impact is scope-changed (S:C) with high integrity and availability loss - the disclosure's author cautions about regional blackouts in Europe, which should be read as worst-case rather than demonstrated. No public exploit code has been identified at time of analysis, and the principal operational constraint is knowing a target email, which the report notes is obtainable by a legitimate sub-account holder who can view the email associated with their parent organization.
Cross-tenant information disclosure in wger allows an authenticated trainer account that holds both the gym.gym_trainer and gym.add_adminusernote permissions but has no gym assignment (userprofile.gym = None) to read private admin notes, uploaded documents, gym contracts, user configuration and permission data belonging to any other unassigned (gym = None) user on the same instance. The root cause is an authorization guard that fails open: the five affected views compare gym objects with the Python operator '!=', and 'None != None' evaluates to False, so HttpResponseForbidden is never reached and the following queryset is filtered only by the attacker-supplied member_id. Rated CVSS 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, authenticated, low privilege), the bug is amplified because gym = None is the default state for newly registered users, so any instance with public registration plus delegated trainer permissions is exposed; a detailed proof-of-concept is documented in the published GitHub advisory and the permission-edit endpoint is also reachable, giving a possible privilege-escalation path, though no confirmed in-the-wild exploitation has been reported.
MISP instances configured to force TOTP enrolment (Security.otp_required) could be used indefinitely by an authenticated user who never completed second-factor setup, because the enrolment guard in AppController::__verifyUser was enforced only for standard browser requests; AJAX/XHR calls, REST API requests, .json format URLs, restSearch queries and automation actions bypassed the check since those request shapes cannot follow the redirect to the TOTP page. The affected range is MISP versions below 2.5.48, and exploitation requires a valid authenticated session for an account that has not enrolled in TOTP and whose role lacks perm_skip_otp, with identities authenticated by API key explicitly exempt (logged_by_authkey). Assessed impact is high for confidentiality and integrity (CVSS 3.1 7.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), with no public exploit identified at time of analysis; risk is real but conditional on the non-default otp_required hardening setting, so patched builds should be applied on a normal, prioritized schedule rather than as an emergency.
Authentication bypass in Express Gateway through 1.16.11 (CWE-287) allows an attacker holding any valid registered OAuth 2.0 client credentials and the identifier portion of another user's refresh token to exchange it for that user's access token, impersonating the victim against OAuth2-protected APIs. The flaw is in the refresh_token grant handler, which never validates the refresh token's secret component or confirms that the presenting client is the client the token was issued to, producing high confidentiality and integrity impact with no availability impact (CVSS 4.0 base 7.6). Exploitation requires low-privileged access plus prior knowledge of the victim's token identifier (PR:L, AC:H), making this a targeted impersonation primitive rather than a mass-exploitable bug; no public exploit identified at time of analysis.
Unauthenticated authentication bypass in Manacle Technologies' Multi-Tenant ERP System lets a remote attacker forge payment-callback requests to mint a valid authenticated session as an arbitrary user, yielding full read and write access to that account and, given the multi-tenant design, potentially to data across tenant boundaries. Per the independent assessment (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) this is a genuine high-priority issue rather than an inflated score: exploitation requires no credentials and no user interaction, but it does depend on the payment-callback API being network-reachable and on the payment-integration feature being enabled and in use. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); the CPE data does not pin specific affected versions.
Unauthenticated payment-result forgery in the Nexi XPay Build WordPress plugin through 7.6.2 lets any remote attacker mark arbitrary orders as paid or failed, cancel those orders at will, and retrieve the order keys that unlock guest buyers' personal details. The vulnerable surface is the plugin's payment-result handling routes, which accept a supplied payment result without verifying it, so no credentials, user interaction, or non-default configuration are needed beyond a site running the plugin as an active Nexi XPay gateway. Publicly available exploit code exists via the WPScan advisory, and although there is no confirmed active exploitation (not listed in CISA KEV), the high integrity impact on order state and the exposure of guest customer data make this an actionable priority; exploitation is limited in practice only by the narrow installed base of this specific gateway plugin.
Unauthenticated remote attackers who can reach the lmadmin management service can seize a privileged administrator session by abusing a hardcoded authentication path in its SOAP handler, granting full control over the license server's administrative functions. The flaw is rated CVSS 9.3 by the reporter and was independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, meaning no credentials or user interaction are required and the confidentiality, integrity and availability impacts are all high. No public exploit code or confirmed active exploitation was identified at time of analysis, but the low complexity, network vector and administrative payoff make this a genuine high-priority issue for any organization exposing lmadmin beyond a trusted management network.
Windows logon token reuse in wolfSSHd versions 1.4.15 through 1.5.0 allows an authenticated low-privilege user to impersonate a higher-privileged user by exploiting a failure to release the Windows logon token between authenticated connections. Only the Windows port is affected; non-Windows builds are explicitly unaffected. Exploitation depends on a timing overlap with a privileged user's login (assessed as a race condition, AT:P in CVSS 4.0 and AC:H in the independent CVSS 3.1 assessment), and no public exploit identified at time of analysis. Upstream fix commits are available and the vendor advisory is published; severity is assessed as High (CVSS 4.0 7.7).
Candlepin, the entitlement and subscription management engine behind Red Hat Satellite 6, contains an authorization-logic flaw in its central access control filter: when an API operation verifies multiple @Verify-annotated parameters, access is granted if any one of them is permitted rather than requiring permission on all of them. An authenticated attacker with a low-privilege account who legitimately can reach the first referenced object can therefore pass authorization checks on later parameters and, provided they know the victim resource identifiers, read consumer information or modify entitlements and subscription resources - including objects belonging to other organizations (CVSS 3.1: 8.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N). Exploitation requires a valid account and prior knowledge of target consumer UUIDs, entitlement IDs, or subscription resource IDs, and is limited to endpoints that evaluate more than one verified parameter; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
Remote code execution affects IBM Langflow OSS versions 1.0.0 through 1.12.2, where improper access control lets an attacker with a valid low-privilege account execute arbitrary code on the server. The flaw is network-reachable with low attack complexity and no user interaction (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8), but it is gated by the requirement to hold an authenticated account, so exposure is greatest where the platform offers open self-service registration, uses shared credentials, or is internet-facing without network restrictions. No public exploit code has been identified and the issue is not listed as confirmed actively exploited (CISA KEV) at time of analysis; exploitation status and patch availability should be re-checked against the IBM advisory.
Sensitive information disclosure in IBM Langflow OSS 1.0.0 through 1.12.2 allows a remote, low-privilege authenticated attacker to retrieve objects belonging to other users by manipulating a user-controlled identifier that the application fails to scope to the requesting principal (CWE-639, IDOR-style authorization bypass). The flaw is network-reachable with low attack complexity and no user interaction, but it is gated on the attacker already holding valid credentials for a low-privilege account (CVSS PR:L); the assessed impact is a high-confidentiality, read-only exposure with no demonstrated integrity or availability effect, so realistic risk concentrates in multi-user or multi-tenant Langflow deployments where a low-trust account can reach another tenant's or user's data. Patch available per vendor advisory (IBM support node 7290694); no public exploit identified at time of analysis.
Improper access control in the vertex result caching subsystem of IBM Langflow OSS 1.0.0 through 1.12.2 lets a remote authenticated attacker read sensitive cached data or inject malicious content into vertex results that other users then consume. The issue carries a CVSS 3.1 base score of 8.3 (High) under the vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L, meaning it is network-reachable with low complexity and requires only a low-privileged account, while yielding high confidentiality and integrity impact and low availability impact. No public exploit code has been identified at time of analysis and the flaw does not appear in CISA KEV; IBM has published a patch advisory (node/7290694), so exposure is limited to unpatched deployments and to attackers who already hold valid credentials on the instance.
Broken access control in Gitea's push-mirror API (CVE-2026-86684) lets an authenticated repository administrator push a repository's refs into an existing Git repository located on the server's local filesystem, using the permissions of the Gitea process rather than the caller's own privilege. Exploitation requires three conditions to hold simultaneously: the instance must be configured with [security] IMPORT_LOCAL_PATHS = true (not a default setting), the attacker must hold repository-administrator rights on a repository whose owner holds the AllowImportLocal permission (the owner's permission is what the flawed check inspected), and a writable Git repository must already exist at the chosen path. The integrity-only impact (CVSS 3.1 7.1, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N as independently assessed) and non-default prerequisites mean real-world risk is lower than the headline score implies; no public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is 0.15% (3rd percentile).
Authenticated users of Backstage Scaffolder can bypass administrator-configured action restrictions in @backstage/plugin-scaffolder-backend by supplying a restricted input value with different letter casing or as a different JSON type (for example a number instead of a string), causing permission checks to fail to match and letting the action execute with the backend integration's credentials. This can grant unauthorized access to repositories and related source-control resources, bounded by the privileges of the integration tokens attached to the affected actions. The issue affects versions before 3.3.1, 3.4.1, 4.0.3, and 4.1.0, and only matters in deployments that actually use input-value-based permission rules; no public exploit code has been identified at time of analysis.
OAuth2 token-endpoint misuse in Gitea 28.0.0 and earlier allows anyone holding a valid, unexpired OAuth2 access token to submit it under the refresh_token grant and receive a brand-new access token plus refresh token, effectively extending access past the credential's original expiry. Exploitation requires a pre-existing valid access token issued for the same OAuth2 application and grant, so this is a persistence/escalation-of-lifetime flaw rather than an entry point for an unauthenticated outsider; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (NVD rates it 9.1 with PR:N). Multi-source signals conflict: NVD's score and CISA's SSVC rating of total technical impact are severe, while EPSS is only 0.17% (6th percentile) and SSVC lists exploitation as none - no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Improper authentication in the Backstage @backstage/plugin-auth-backend-module-oidc-provider package prior to 0.4.20 lets an authenticated user of a configured OIDC identity provider impersonate another catalog identity. Exploitation requires a deployment that resolves sign-in identities by matching the OIDC email claim AND an identity provider that issues email addresses without asserting email_verified=true, in which case the attacker's unverified, self-controlled email can match a victim's catalog identity and inherit that identity's access and permissions (CVSS 3.1 base 8.1, PR:L, no availability impact). No public exploit code has been identified at time of analysis, and the flaw is fixed by omitting the email from the default OIDC profile transform unless the provider explicitly marks it verified.
Unauthenticated attackers who can reach Gitea's web installer on an instance whose INSTALL_LOCK has been reset to false (or is otherwise unset) can obtain a fully authenticated session for any existing account - including an administrator - simply by submitting the install form with a username that matches that account, with no password verification whatsoever. Full administrative takeover follows, allowing the attacker to change the account's password and control the instance. The bypass only exists while the installer is network-reachable against a database that already contains users; the default hardened post-install state (INSTALL_LOCK=true) is not affected. Independent assessment rates this CVSS 8.1 (AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:H); EPSS is low at 0.16% (4th percentile) and no public exploit code has been identified at time of analysis.
Gitea 1.27.3 and earlier misattributes the pushing identity to the repository owner whenever a git push is authenticated with a repository deploy key, causing the pre-receive hook pipeline to evaluate permissions against the owner rather than the deploy key. An attacker holding a write-enabled deploy key can therefore create protected tags despite not being on the tag allow list, or flip repository visibility (for example private to public) through git push options, and pull requests created via the AGit flow are likewise attributed to the owner. Access is gated: a read-only deploy key is insufficient, exploitation requires an authenticated push (CVSS PR:L), no public exploit code has been identified at time of analysis, EPSS is only 0.15% (3rd percentile), and CISA SSVC rates exploitation as none with partial technical impact.
Information disclosure in the HPE Networking ClearPass Policy Manager Android client application allows an unauthenticated remote attacker to invoke improperly access-controlled application functionality from an untrusted source, potentially exposing sensitive information held on or accessible to the victim's mobile device. Exploitation requires the ClearPass Android client to be installed plus mandatory victim interaction (UI:R) with attacker-supplied content - for example a malicious co-installed app, crafted intent, deep link, or content - so delivery likely relies on an Android inter-component path rather than direct internet-facing exposure, and no public exploit was identified at time of analysis. Note that the vendor-supplied CVSS 3.1 vector (8.8, C:H/I:H/A:H) overstates the issue relative to the described confidentiality-only impact; our independent assessment limits the score to AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N.
Authentication bypass in HPE Aruba Networking ClearPass Policy Manager allows an unauthenticated remote attacker to circumvent existing authentication controls on the affected interface and gain unauthorized access to the system, rated CVSS v3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). No public exploit code was identified and the vulnerability is not confirmed actively exploited (no CISA KEV), but the assessed vector shows no credentials, no user interaction and no special configuration required, implying default-configuration exploitability where the interface is reachable. Independent assessment concludes the available signals point to a genuine high-priority issue rather than a CVSS-inflated non-issue; the exact affected versions and the specific exposed service are not named in the available HPE bulletin, so exposure of the interface is the primary risk-limiting factor.
Authentication bypass in HPE Networking ClearPass Policy Manager allows an unauthenticated remote attacker to circumvent existing authentication controls on the product's web-based management and API interfaces and obtain administrative access to the affected system. The flaw carries a vendor-assessed CVSS of 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), meaning no credentials, no user interaction, and no special configuration are required - only network reachability to a management or API endpoint, which in many deployments is restricted to management VLANs or admin networks, making exposure control the primary practical limiting factor. Our assessment rates this a genuine top-priority vulnerability rather than a high-CVSS-but-low-real-risk case; no public exploit code and no confirmed active exploitation were identified at time of analysis, and ClearPass is a network access control / policy enforcement platform, so administrative compromise can extend impact well beyond the appliance itself.
Authentication bypass in the Aruba AOS-S (HPE Aruba Networking switch) management interface could allow an unauthenticated remote attacker to gain unauthorized access to the affected system, but exploitation is constrained by high attack complexity (AC:H) and specific preconditions outside the attacker's control that HPE has not publicly detailed. No public exploit code or CISA KEV active exploitation has been identified at time of analysis. Although the nominal CVSS 3.1 base score is 9.8 CRITICAL, the assessed vector emphasizes that successful attacks are not reliable against an arbitrary default deployment, and HPE advisory hpesbnw05156en_us should be consulted for exposure details.
Unauthenticated remote attackers can bypass authentication in the web management interface of HPE AOS-S (ArubaOS-Switch), gaining full administrative control of the switch, as reflected in the 9.8 CVSS score (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Any device with the HTTP/HTTPS management service reachable from an untrusted network is exposed, and because the vector requires no credentials and no user interaction, network reachability of that interface is the primary limiting factor. No public exploit code was identified at time of analysis and there is no CISA KEV confirmation of active exploitation; this is a genuine high-priority issue whose exact affected firmware versions and fixed releases are not detailed in the available data and must be confirmed against the HPE advisory.
Gitea Actions in versions up to and including 1.27.3 can execute workflow code from an untrusted fork pull request head on the repository's runners without the maintainer approval that the first-time-contributor gate is supposed to require. An authenticated user holding Actions write permission can cancel a run that is still awaiting approval and then re-run it; the rerun path recreated the attempt's jobs as waiting instead of blocked while the run still recorded that approval was required, so the jobs were released without an approval decision. Signals point to a genuine but not emergency-grade issue: exploitation requires Actions enabled, a registered matching runner, a fork pull request from a first-time contributor, and Actions write access (CVSS PR:L), no public exploit code was identified at time of analysis, and EPSS is low at 0.16% (4th percentile).
Access-control bypass in SSSD lets an already-authenticated user from a trusted identity domain reach hosts and services that Host-Based Access Control (HBAC) rules are supposed to protect. Because SSSD strips the domain qualifier and compares only short usernames during HBAC evaluation, a trusted-domain user whose short name collides with an authorized local account is silently granted that local account's access. Publicly available exploit code exists, but exploitation is not automatable and EPSS is low at 0.28% (18th percentile); exposure is limited to trust-enabled FreeIPA/IdM-style deployments that delegate host access decisions to SSSD.
Incorrect authorization in Elasticsearch 8.x and 9.x allows an authenticated, already-privileged user (CVSS PR:H) who has been granted a non-default, delegated role-management privilege to escalate privileges within a cluster. By abusing a role-definition setting that expands the set of indices matched against a delegated index-scoped privilege, the holder can modify their own assigned role and reach indices that should remain restricted, including internal security data, and from there potentially obtain full administrative control of the cluster. Exploitation is only possible when the cluster has the configurable delegated role-management privilege explicitly enabled and granted with a broadly-scoped index pattern; default deployments that never delegate this capability are not affected. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV). Vendor-released patches are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4.
Authorization bypass in Kibana's Fleet package installation process lets an authenticated user who holds delegated Fleet package-management privileges - but no direct Elasticsearch administrative rights - claim a data stream identifier already in use by another tenant sharing the same deployment. Because Fleet does not verify ownership of that identifier before applying the uploaded package's generated index and ingest-pipeline settings to pre-existing infrastructure, an attacker can redirect a victim tenant's subsequent data through infrastructure they control, achieving unauthorized disclosure and modification of that data and preventing it from reaching its intended destination (CVSS 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Exploitation requires a multi-tenant Kibana deployment with delegated Fleet privileges and valid authenticated access; it is impossible in single-tenant setups, and no public exploit identified at time of analysis.
In Arista CV-CUE, an unauthenticated attacker can forge their apparent source IP address and obtain administrative session privileges on the CV-CUE backend, effectively bypassing authentication (CWE-290). The attacker must either be positioned on an adjacent private network segment reachable by the backend, or route requests through a reverse proxy or load balancer that forwards client-supplied headers such as X-Forwarded-For without sanitising them; no credentials and no user interaction are required. Rated CVSS 4.0 8.7 (and scored 8.7-equivalent high impact under the independent CVSS 3.1 assessment with AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H), this is a credible high-priority authentication-bypass issue. There is no public exploit identified at time of analysis, and exploitation is bounded by network reachability and header-handling configuration in front of the backend. Patch availability is not confirmed in the provided data; consult the Arista security advisory 0190.
Unauthenticated network attackers can reach backend functionality in Arista CV-CUE that is intended only for internal services, giving them access to sensitive location information and the ability to disrupt affected services. The root cause is a missing authentication check (CWE-306) on internal-service endpoints, rated 9.3 under CVSS 4.0 with a vector of AV:N/AC:L/AT:N/PR:N/UI:N and high confidentiality, integrity and availability impact within the vulnerable component; an independent assessment agrees the flaw is remotely reachable and requires no credentials, configuration change or user interaction, but stresses that the real-world exploitability depends on network exposure. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the practical limiting factor is whether the internal endpoints are exposed to untrusted networks or are segmented behind a trusted management network.
Server-side request forgery in Gitea 1.27.3 and earlier allows an authenticated user with permission to start repository migrations to reach internal services by pointing an allow-listed migration hostname at a loopback or private address, bypassing the ALLOW_LOCALNETWORKS=false restriction. Exploitation requires the optional [migrations] ALLOWED_DOMAINS allow-list to be configured (default installations are unaffected by this specific bypass), valid migration rights (CVSS PR:L, authenticated), and attacker control over DNS resolution for a hostname already present in that allow-list. No public exploit code or confirmed active exploitation was identified at time of analysis; the root-cause class is network-restriction bypass (SSRF-style) rather than an authentication bypass, despite that tag in the source data.
Insufficient audience validation in Backstage's Cloudflare Access auth provider package (@backstage/plugin-auth-backend-module-cloudflare-access-provider 0.1.0 through 0.4.x) lets a user who already holds a valid Cloudflare Access JWT issued for a different Access application inside the same Cloudflare Zero Trust team authenticate to Backstage, because the provider verifies the token signature and team issuer but never checks the token's audience (AUD) claim. Exploitation is conditional: the forged-context token must actually reach the Backstage auth endpoint on a path where Cloudflare Access has not already enforced the Backstage application's own AUD tag upstream, and the attacker must be an authenticated member of the shared Zero Trust team, which is why the assessed vector carries AC:H and PR:L and the resulting rating is a moderate, conditional authentication bypass rather than a top-tier priority. No public exploit code has been identified at time of analysis, and the issue is fixed in plugin version 0.5.0 (shipped with Backstage v1.55.0), where the 'audience' configuration value becomes mandatory.
Authorization bypass in the optional Amazon Q Business Lambda hook sample shipped alongside QnABot on AWS 7.0.0 through 7.4.5 lets an authenticated remote user cause the hook to read arbitrary Amazon S3 objects in the deploying AWS account, exposing data the caller should not be able to reach. Only customers who separately and manually deployed the q-business-lambda-hook sample stack on top of an affected QnABot version are exposed; the hook is not installed by default and the impact is limited to confidentiality within that account. Vendor-released patch: 7.4.6, and no public exploit identified at time of analysis. Per the authoritative assessment this is a moderate, conditional risk rather than a widespread emergency, because exploitation depends on the optional component being present, on authenticated access to the hook's request path, and the resulting impact is S3 object read only.
Missing authorization checks in the MultiversX 'multisig-improved' reference smart contract (mx-multisig-and-modules) allow an account holding the Proposer role to unilaterally move funds, draining 100% of a deployed contract's EGLD/ESDT balance in as few as two transactions with zero board signatures. The flaw is a CWE-306 missing-authentication issue in the fund-moving execution path; exploitation requires the attacker to already hold the Proposer role on a specific vulnerable deployment (assessed as PR:L, authenticated), not fully anonymous access, and publicly available exploit code exists, though there is no confirmed active exploitation (no CISA KEV) and EPSS is only 0.15% (3rd percentile). Deployments built from the affected commit are fully exposed once a Proposer-role account is compromised or malicious.
Configuration-controlled code execution in the hydra-optuna-sweeper package (Hydra 1.2.0 up to but not including 1.3.0, plus 1.4.0 development builds before 1.4.0.dev10) allows an attacker who controls Optuna sweep configuration or command-line overrides to name an arbitrary importable Python callable in hydra.sweeper.custom_search_space that Hydra resolves and then invokes inside the controller process at the application's privilege level, including bypassing the trusted execution whitelist introduced on affected 1.4.0 development releases. The assessed CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8 High): delivery is local and unauthenticated, but a victim must actually launch the sweep, after which confidentiality, integrity, and availability impact is total for the affected process. Exploitation is only meaningful where sweep configuration or overrides cross a trust boundary; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Incomplete cleanup in the Chromoting (Chrome Remote Desktop) component of Google Chrome on macOS before 155.0.8059.39 lets a remote, unauthenticated attacker bypass system access restrictions using crafted network traffic, per the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N vector. Impact is materially constrained: only macOS hosts on an affected build with Chromoting enabled and reachable are in scope, and the realistic outcome is limited information exposure rather than full compromise, which is consistent with the vendor's 'Low' Chromium severity rating. Risk signals conflict sharply - the supplied CVSS score of 9.1 (C:H/I:N/A:H) and the authoritative assessed vector of C:L/I:N/A:N disagree - and must be reconciled before prioritization; EPSS is negligible at 0.17% (6th percentile), there is no KEV listing, and no public exploit identified at time of analysis. Vendor-released patch: Chrome 155.0.8059.39.
Authorization bypass in the Chromoting (Chrome Remote Desktop) host component of Google Chrome on macOS prior to 155.0.8059.39 lets remote attackers circumvent macOS system access restrictions by sending crafted network traffic to the remoting service; the provided CVSS vector is AV:N/PR:N/UI:N so the flaw is treated as network-reachable and unauthenticated. Exploitation is conditional rather than opportunistic: it requires Chrome Remote Desktop (Chromoting) to be installed, enabled and network-reachable on a macOS host, and Google's Chromium team rated the underlying defect only 'Low' severity, which is why our independent assessment reduces impact to C:L/I:L/A:N with AC:H instead of the vendor's 9.1. No public exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is low at 0.21% (10th percentile), so this should not be triaged as a 9.1-equivalent emergency even though the vendor score is high.
Google Chrome for Android prior to 155.0.8059.39 contains an incorrect-authorization flaw in its Transactions Platform component that lets an unauthenticated remote attacker read sensitive information from the browser by luring the victim into opening a crafted HTML page. No public exploit code has been identified at time of analysis and the issue is not reported as actively exploited, though the attack is fully remote (AV:N/PR:N) and requires only that a user on a vulnerable Android build load the attacker's page (UI:R). Note that public severity signals conflict: the vendor rates this Chromium security severity 'Low' and limits impact to information disclosure, while a widely replicated CVSS 3.1 base score of 8.8 lists high integrity and availability impact that is not supported by the description - our independent assessment scores it 8.8-adjacent only on confidentiality (C:H/I:N/A:N).
The signals here conflict sharply and must be reconciled before prioritization: the supplied CVSS 3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and the 'Authentication Bypass' tag imply full compromise, while the authoritative assessed vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N describes only a confidentiality impact with mandatory user interaction. As assessed, an unauthenticated remote attacker can obtain sensitive information from Google Chrome desktop builds prior to 155.0.8059.39 when a victim opens a crafted HTML page, with no integrity or availability impact and no authenticated-session or special-configuration prerequisite in the product itself. There is no CISA KEV listing and no public exploit code identified at time of analysis, Chromium rates the underlying issue Low severity, and the vendor-released patch is Chrome 155.0.8059.39.
Information disclosure in Google Chrome for Android (versions prior to 155.0.8059.39) allows remote, unauthenticated attackers to reach sensitive data held by the browser's Autofill feature via a crafted HTML page, with the flaw rooted in incorrect authorization (CWE-863) in the Autofill path. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), exploitation requires the victim to actively navigate to the attacker's page and the impact is confined to confidentiality, with no integrity or availability effect; the vendor-supplied 8.8 score (C:H/I:H/A:H) and the 'Low' Chromium severity conflict with this assessment and should be reconciled before prioritization. Chrome on Android is the affected build, no public exploit was identified at time of analysis, and a vendor-released patch (155.0.8059.39) is available.
Origin policy bypass in Google Chrome for Android prior to 155.0.8059.39 lets a remote attacker acting through a confused deputy have actions carried out under a different web origin's authority, so a victim who is socially engineered into opening a crafted HTML page can have that page reach resources or capabilities it should never hold for its own origin. Only Chrome on Android is affected, exploitation is not silent (it requires the user to open attacker-supplied content, CVSS PR:N/UI:R), and no public exploit code or active exploitation has been identified at time of analysis; EPSS is 0.22% (12th percentile), and Google rates the underlying Chromium bug as Low severity. Note the sharp signal conflict that must be reconciled before prioritization: the nominal vendor CVSS is 8.3 while EPSS, vendor severity, and our independent assessment (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N) all point to materially lower real-world risk.
Site isolation bypass in Google Chrome for Android (versions prior to 155.0.8059.39) lets an attacker who has already compromised the renderer process cross the per-site process boundary and reach data that should remain isolated to other origins, triggered when the victim loads a crafted HTML page. It is a second-stage flaw rather than an initial-access vector: exploitation is gated on a separate, pre-existing renderer compromise plus required user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N), which is why the vendor assigned a Chromium severity of Low even though the base score is 8.2. No public exploit identified at time of analysis, no CISA KEV listing, and EPSS is only 0.21% (11th percentile); a vendor patch is available, so the residual risk is concentrated in unpatched Android clients that are simultaneously exposed to a first-stage renderer exploit.
Incorrect authorization in the Selection component of Google Chrome for iOS lets a remote, unauthenticated attacker obtain sensitive information when a victim opens a crafted HTML page, and the issue is resolved in Chrome 155.0.8059.39. Only the iOS build of Chrome below that version is in scope; desktop and Android builds are not named as affected, and exploitation requires the user to actively visit the attacker-controlled page (UI:R per the assessed vector). No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so the practical risk is bounded by mandatory user interaction, the narrow iOS-only affected population, and the fact that a vendor fix already ships; note that the supplied base score of 8.8 (C:H/I:H/A:H) is inconsistent with both the Chromium 'Low' severity label and the assessed vector, which rates impact as confidentiality-only.
Missing authorization in the Actor component of Google Chrome prior to 155.0.8059.39 allows code to escape the browser sandbox, but only after the attacker has already compromised the renderer process via a separate bug and then gets the victim to load a crafted HTML page. This prerequisite, combined with required user interaction (UI:R) and high attack complexity (AC:H) from the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H vector, means the flaw is only usable as a link in an exploit chain rather than as a standalone initial-access vector; the changed scope (S:C) and high confidentiality, integrity and availability impact reflect the potential for full code execution outside the sandbox. No public exploit code identified at time of analysis and there is no confirmed actively exploited (CISA KEV) status, so risk should be weighed against the conflicting 8.3 score versus the demanding exploitation preconditions. A vendor patch is available in Chrome 155.0.8059.39.
Incorrect authorization in the Google Chrome user-interface layer allows a crafted HTML page to escape the renderer sandbox and execute arbitrary code outside it on all Chrome builds prior to 155.0.8059.39. Exploitation requires the victim to open an attacker-supplied page (UI:R in the assessed vector) and, while no authentication is required (PR:N) and no unusual configuration is needed, the attack is not fully remote - it depends on that user action, which is the main limiting factor. Severity signals are mixed: the assessed CVSS vector scores 9.6 with scope change (S:C) and high confidentiality, integrity and availability impact, yet Google rates the underlying Chromium issue as Medium, and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Incorrect authorization in Google Chrome's WebProtect component lets a remote, unauthenticated attacker who socially engineers a victim into opening a crafted HTML page read sensitive information held in the browser context - the assessed impact is confidentiality-only (C:H/I:N/A:N), with no integrity or availability loss. Every Chrome build prior to 155.0.8059.39 is affected across platforms, and Google rates the underlying issue as Chromium security severity Medium. Exploitation is not drive-by: the CVSS vector requires user interaction (UI:R) and PR:N, so no credentials or non-default configuration are needed but the victim must be lured to the attacker-controlled page, and no public exploit code has been identified at time of analysis, making the base score of 8.8 an overstatement of realistic risk.
Site isolation bypass in Google Chrome affects versions prior to 155.0.8059.39, where a missing authorization check (CWE-862) in the browser's Workers implementation lets an attacker who has already compromised a renderer process cross the site-isolation boundary using a crafted PDF file. The attack is remote (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1), but exploitation is gated on a pre-existing renderer foothold obtained through a separate vulnerability, so this is a chained sandbox/site-isolation escape rather than a standalone remote compromise. There is no public exploit identified at time of analysis and no CISA KEV listing; EPSS is low at 0.17% (5th percentile), and CISA SSVC rates exploitation as 'none' with automation as 'no', while acknowledging total technical impact if the chain is completed. A vendor patch is available in Chrome 155.0.8059.39.
Incorrect authorization in Google Chrome's Autofill feature (versions prior to 155.0.8059.39) allows an unauthenticated remote attacker (PR:N) to obtain sensitive information via a crafted HTML page, but exploitation requires social engineering to trick the victim into visiting and interacting with the page (UI:R). The independent assessment limits the impact to confidentiality (C:L) with no integrity or availability effect, and exploitation further depends on the victim having relevant data stored in Autofill; no public exploit or active exploitation has been identified. A vendor patch is available.
Confused-deputy bypass in Google Chrome's Contextual Tasks feature allows a remote attacker who already holds renderer code execution to cross a security boundary into a privileged page by loading a crafted HTML page, with high confidentiality and integrity impact (unauthenticated per the CVSS vector, but requiring user interaction). The flaw affects Chrome builds prior to 155.0.8059.39 and functions primarily as a chain link - the prerequisite renderer compromise from a separate bug is the real gate, which sharply narrows standalone risk despite the 8.1 score. No public exploit code has been identified at time of analysis and EPSS is very low at 0.18% (7th percentile), with CISA SSVC recording no observed exploitation; a vendor-released patch exists in 155.0.8059.39.
Site isolation bypass in Google Chrome versions earlier than 155.0.8059.39 lets a remote attacker who has already compromised a renderer process escape Chrome's process boundary and reach data or privileged accessibility functionality belonging to other origins by way of a crafted HTML page the victim loads. The flaw is an incorrect-authorization bug (CWE-863) in the browser's Accessibility component, making it a chained, second-stage primitive rather than a standalone remote compromise, which is why the assessed vector uses AC:H (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) despite an underlying base score of 8.1. Google has released a vendor patch in 155.0.8059.39; no public exploit code and no confirmed active exploitation were identified at time of analysis (EPSS 0.18%, CISA SSVC exploitation: none, automatable: no), so the risk is real but is not currently a frontline emergency.
Arbitrary code execution outside Chrome's sandbox on Android affects Google Chrome builds prior to 155.0.8059.39, where a missing authorization check (CWE-862) can be abused by a malicious co-installed Android app. The attack is local - it requires an attacker-controlled app to already be present on the same device plus successful social engineering to get the victim to install it and trigger the action - so a default, lone Chrome installation is not directly exploitable. Google rates this Chromium security severity Medium, the vendor CVSS is 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) while our assessment substitutes UI:R, no publicly available exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is only 0.12% (2nd percentile).
Site isolation bypass in Google Chrome on Android (prior to 155.0.8059.39) allows an attacker who has already compromised the renderer process to reach the browser's Passwords component via a crafted HTML page and a missing authorization check, exposing stored credential data. The bug is a chained, second-stage issue: it cannot be triggered by an unprivileged remote attacker without pre-existing renderer code execution, and it requires user interaction to load the crafted page, which is why the assessed vector (AV:N/AC:H/PR:L/UI:R/C:H/I:N/A:N) makes realistic risk LOW despite the 8.1 base score. No public exploit identified at time of analysis, EPSS is only 0.21% (11th percentile), CISA SSVC records Exploitation: none, and Google rated the Chromium security severity Medium, so this is a routine patch-cycle fix rather than an emergency.
Sensitive-information disclosure in Google Chrome for iOS before 155.0.8059.39 allows a remote, unauthenticated attacker to abuse a missing authorization check by socially engineering a victim into opening a crafted HTML page. The independent assessment limits the impact to confidentiality (C:H/I:N/A:N), so this should be treated as an information disclosure issue rather than code execution or data tampering, and exploitation requires user interaction on the iOS build only. Vendor patch 155.0.8059.39 is available, and no public exploit code or CISA KEV active exploitation was identified in the supplied intelligence.
Remote attackers can bypass system access restrictions and reach a privileged internal page in Google Chrome for Android versions prior to 155.0.8059.39 by way of a confused-deputy weakness in the SignIn component, which performs privileged navigation on behalf of an untrusted caller. Exploitation requires the victim to load attacker-controlled crafted HTML (for example, visiting a malicious or compromised page), needs no authentication or prior privileges, and is limited to the Android build on pre-patch versions. No public exploit code has been identified at time of analysis, EPSS is low at 0.22% (12th percentile), and the issue is not confirmed as actively exploited; a vendor patch (155.0.8059.39) is available, so this is a moderate-priority patch-and-move-on item rather than an emergency.
Cross-origin data disclosure in Google Chrome (all versions prior to 155.0.8059.39) stems from a missing authorization check in the browser's FileSystem component, allowing a crafted HTML page to breach the web origin boundary and read data it should not reach. Exploitation is strictly a second-stage condition: an attacker must first have already compromised Chrome's renderer process through a separate flaw, and the victim must load attacker-controlled content (UI:R), so a default, fully patched Chrome with an intact renderer sandbox is not directly exploitable - a limitation that makes real-world risk moderate despite the 8.2 base score, and is reflected in the low EPSS of 0.22% (12th percentile). Google has shipped a fix in Chrome 155.0.8059.39, there is no confirmed active exploitation (CISA KEV) and no public exploit identified at time of analysis.
Quick Facts
- Typical Severity
- CRITICAL
- Category
- auth
- Total CVEs
- 42440