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)
Unauthenticated access to the backup function on the Kaon AR2140X router allows an attacker on an adjacent network segment to trigger a configuration export without any credentials and download the resulting file, which is protected only by a device-specific encryption key. The same action drives the router into an inoperable state for a substantial period, making availability loss the dominant realistic impact, while the device-specific backup encryption limits direct confidentiality exposure. Affected firmware is reported up to version 4.2.17, with the status of newer releases unknown; exploitation requires network adjacency (same LAN, Wi-Fi, or adjacent ISP access segment) rather than internet exposure, no authentication or user interaction is needed, and no public exploit code was identified at time of analysis.
Improper authorization in Apache SkyWalking BanyanDB 0.11.0 allows a user holding only a readonly Canopy role to push non-read requests through the Canopy monitoring proxy to a configured monitoring target, effectively escalating a read-only account into a write-capable path. The flaw is reachable only under a non-default deployment in which the experimental Canopy proof-of-concept role system and the monitoring-proxy feature are both enabled and a monitoring target is configured, and the attacker must already hold a valid low-privilege Canopy credential; the headline CVSS of 9.1 assumes PR:N/AC:L, which conflicts with this assessed PR:L/AC:H profile. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and EPSS is low at 0.15% (4th percentile), reflecting the narrow configuration prerequisites. Users should upgrade to 0.11.1, which fixes the issue.
Authorization bypass in Enocta Platform (all versions through 2026-09-28) lets an authenticated low-privilege user read or alter other users' records by tampering with a user-controlled identifier in requests. With a CVSS 3.1 base score of 8.1 (High), the flaw yields high confidentiality and integrity impact but no availability impact. No public exploit code has been identified and the issue is not in CISA KEV; exploitation requires a valid low-privilege account on the platform.
Authenticated low-privilege attackers can invoke destructive PostgreSQL database operations in Zoho ManageEngine DDI Central by exploiting insufficient access control on the high-availability (HA) failover endpoint in all versions before 6201. With a CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), the flaw is network-reachable, requires only low-privilege credentials and no user interaction, and carries full impact to confidentiality, integrity, and availability - an attacker who reaches the failover endpoint can act well beyond their intended permissions. The vendor has published a fix in version 6201, and no public exploit code has been identified at time of analysis; this CVE is not in CISA KEV, so there is no confirmation of active exploitation.
LDAP filter injection in Apache Karaf before 4.4.12 allows a crafted login name to alter the structure of LDAP search filters built by LDAPCache and LDAPBackingEngine, potentially matching an unintended directory entry, over-granting roles, or changing which account a login resolves to. The unescaped value only reaches the filter through two call paths - the GSSAPILdapLoginModule (Kerberos/SPNEGO), which passes the NameCallback name through unescaped, and the LDAPBackingEngine.listRoles path, which passes principal.getName() unescaped - because the default LDAPLoginModule and LDAPPubkeyLoginModule both pre-escape the login name via Util.doRFC2254Encoding(). The issue is remote and unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, score 7.3), but real-world impact is bounded by the administrator-configured userFilter/roleFilter templates; there is no confirmed active exploitation (not in CISA KEV), no public exploit code identified at time of analysis, and EPSS is low at 0.25% (14th percentile). A vendor patch is available in Apache Karaf 4.4.12.
Missing authorization in Netcore NBR100V2 firmware 1.3.240614.030928 allows remote unauthenticated attackers to modify device configuration via the uci.apply function, as the /usr/share/rpcd/acl.d/unauthenticated.json ACL incorrectly grants this function to unauthenticated callers. Publicly available exploit code exists, and the vendor has not responded to disclosure attempts, so no vendor-released patch is identified at time of analysis. The primary exploitation barrier is network reachability to the router's rpcd/ubus management interface, which is typically LAN-bound unless exposed to the WAN.
Improper authentication in the Debug Service of Seetong T8108, T8108P, T8116, and T8232 devices running firmware 4.6.1.4-build202604241011 lets unauthenticated, remote attackers bypass authentication and gain full control of the affected device, with the reported CVSS 4.0 base score of 9.3 (independent assessment: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, high confidentiality, integrity, and availability impact). Publicly available exploit code exists - a GitHub proof-of-concept repository targets the Seetong TS81xx series - so any reachable device must be treated as exploitable, although the supplied data contains no CISA KEV entry confirming active exploitation. The vendor was contacted about the disclosure and did not respond, so no vendor patch is available and exposure is the primary limiting factor: the attacker only needs network reachability to the exposed Debug Service (same LAN segment, or an internet-exposed or port-forwarded device).
Authorization bypass in Obot before v0.21.1 lets any authenticated user with a known MCP Server ID connect to restricted MCP servers through the /mcp-connect/{id} gateway endpoint, which fails to enforce Access Control Rules and MCP Registry membership. Because the gateway reuses Obot's stored OAuth/API credentials for the upstream server, an attacker in a Basic role or above can invoke that server's tools - reading and writing data in whatever backends those credentials reach - even when administrators explicitly scoped the server to a small group. Independently assessed at CVSS 9.3, this is a genuine high-priority authorization flaw limited to multi-user deployments that register credential-bearing MCP servers and depend on ACRs for isolation; no public exploit code has been identified at time of analysis, and vendor-released patched version 0.21.1 is available.
Obot deployments started with the README's Docker quickstart expose port 0.0.0.0:8080 with authentication disabled, allowing unauthenticated attackers who can reach that port to take full Owner/Admin control of the Obot API and UI. Because every request is mapped to a synthetic 'nobody' user that already holds Owner and Admin roles, an attacker can register and launch attacker-controlled MCP servers, and since the quickstart also mounts /var/run/docker.sock into the container, that control extends to the host's Docker daemon. All versions through commit d7e6970 are affected; the vendor fix is documentation-only (the quickstart now enables authentication), no public exploit code has been identified at time of analysis, and instances are safe only if the operator set OBOT_SERVER_ENABLE_AUTHENTICATION=true or kept port 8080 off untrusted networks.
OAuth dynamic client registration in Obot through v0.22.1 allows unauthenticated remote attackers to register an OAuth client pointing at an attacker-controlled redirect URI, then harvest an access and refresh token from a logged-in victim who visits a single crafted authorization URL. The minted token carries the victim's full group set and is accepted as a bearer token against any Obot API endpoint the victim can access - not just the requested MCP server - letting the attacker read or modify the victim's resources until the token is revoked. Exploitation is gated by the server running with OBOT_SERVER_ENABLE_AUTHENTICATION=true and by required victim interaction (clicking the link); no public exploit code has been identified at time of analysis. Versions v0.23.0 and later add a consent screen, token scoping to the requesting MCP server, and audience validation.
Heym deployments prior to 0.0.53 leave their Telegram webhook endpoints without verification of the X-Telegram-Bot-Api-Secret-Token header whenever the endpoint has no credential_id or an empty secret_token, so remote unauthenticated attackers who know the webhook URL can POST forged Telegram updates and cause the owner's configured workflows to run with the owner's stored credentials. The flaw is a fail-open authentication check (CWE-287) rated 8.3 with an assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N profile - confidentiality exposure is limited while integrity impact is high, since attacker-supplied input is processed under the victim's credentials. No public exploit code has been identified at time of analysis, and exploitation requires the precondition of an unset or empty secret token plus at least one workflow wired to Telegram updates.
Forged Slack webhook events can trigger Heym workflows with the owner's credentials because Heym before 0.0.53 skips Slack request-signature verification whenever a Slack trigger node has no credential ID or an empty signing secret (a fail-open code path). The bypass is unauthenticated (CVSS 4.0 PR:N) but conditionally gated: it only works against trigger nodes that are misconfigured this way, and the attacker must know or discover the target's webhook URL - a properly configured node with a valid signing secret is not exploitable, which is why the assessed severity carries AC:H. Impact is primarily integrity (I:H) with limited confidentiality exposure (C:L), and the vendor fixes it in 0.0.53 by making signature verification fail closed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Parse Server deployments running versions 9.0.0 through 9.10.1-alpha.9 or 8.0.2 through 8.6.90 that enable code-based social login adapters (GitHub, Google Play Games, Instagram, LINE, LinkedIn, Microsoft, QQ, Spotify, WeChat, Weibo) fail to re-verify provider credentials when authentication data is submitted alongside a username and password on the login endpoint. An authenticated attacker holding a low-privileged account can therefore attach an arbitrary, unverified external provider identity to their own account - or pre-claim the provider ID of a victim who has not yet linked that provider, so the victim's later legitimate provider sign-in lands on the attacker's account. Exploitation is conditional: it requires a non-default adapter to be configured and a valid authenticated session, and the pre-hijack variant additionally requires the targeted victim to complete a legitimate provider login. No public exploit code or confirmed active exploitation was identified at time of analysis, and the assessed risk is a genuine but conditional authentication flaw rather than a mass-exploitation threat.
Feature policy bypass in Citrix NetScaler ADC and Gateway allows unauthenticated remote attackers to evade certain configured policies when those policies use HTTP URL-based expressions, potentially bypassing policy enforcement controls. Affected are ADC before 14.1-73.37, before 13.1-64.23, before 14.1-73.37 FIPS, and before 13.1.37.279 FIPS/NDcPP; Gateway before 14.1-73.37 and before 13.1-64.23. No public exploit identified at time of analysis, and the vendor advisory CTX697096 covers this issue alongside related NetScaler CVEs; exploitation requires the specific precondition of a URL-based feature policy, which limits real-world risk.
JWT audience confusion in Sylius (before 1.12.25, 1.13.17, 1.14.20, 2.1.16, and 2.2.9) allows a self-registered shop customer to escalate to full administrator access. Because tokens issued by the Shop API omit any firewall/audience identifier, an attacker who registers a shop account using an existing administrator's email address receives a token that the Admin API resolves to that administrator, granting complete administrative control (CVSS 3.1 8.7, PR:L, C/I/A:H). Exploitation requires the default configuration with both Shop and Admin JWT firewalls and self-service shop registration enabled, plus knowledge of the admin's email; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but public patch and GitHub advisory details are available.
Incorrect authorization in the Sylius Shop API lets anyone holding an order token submit arbitrary payment actions - most notably refunds - against their own completed orders through POST /api/v2/shop/orders/{tokenValue}/payment-requests. Affected releases are Sylius versions before 2.1.16 and before 2.2.9; the endpoint accepted any caller-supplied action value with order ownership as the only check, so where a payment gateway wires a refund-class action into its action-indexed command provider the gateway executes the refund while Sylius still records the order as paid, producing direct financial loss. The vulnerability is remote and unauthenticated per the assessed CVSS vector (PR:N) because the order token is held by any customer for their own purchase, but exploitation is gated by that specific gateway configuration (AC:H / AT:P), and no public exploit has been identified at the time of analysis.
Authentication bypass in wolfSSL TLS clients built with Raw Public Key (RPK) support allows a malicious or on-path server to force acceptance of an unsolicited server_cert_type=RawPublicKey extension during a TLS 1.2, TLS 1.3, or DTLS 1.2 handshake, causing the client to treat RPK as the negotiated credential form and skip normal certificate-chain verification. Only builds compiled with HAVE_RPK (--enable-rpk, --enable-all, or --enable-distro) are exposed; default builds are unaffected, and exploitation additionally requires the victim to act as the client connecting to the attacker-controlled server (or an on-path injector) with no user interaction, as reflected by PR:N in the vector. There is no public exploit identified at time of analysis and no CISA KEV listing, though the raw CVSS 4.0 base score of 8.3 contrasts sharply with the non-default, compile-time-gated reachability captured in the independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), so the practical risk is concentrated in RPK-enabled deployments.
wolfSSL builds that enable the WOLFSSL_TRUST_PEER_CERT macro can be induced to accept a forged clone of a trusted-peer CA, letting a malicious (D)TLS server bypass peer authentication; when OPENSSL_COMPATIBLE_DEFAULTS is also defined the flaw spreads to all CA certificate loading. The vulnerable path is reached through wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(), APIs used by autoconf/distro builds of nginx, haproxy, stunnel, wpa_supplicant, apache httpd, hitch, bind, rsyslog and ffmpeg, and exploitation is unauthenticated over the network (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N). The practical barrier is that the attacker must already know which certificates the victim loaded before a matching clone can be forged (assessment- and vendor-cited AT:P), so this is a targeted authentication bypass rather than a mass-exploitable one; patches exist upstream but no public exploit code has been identified at time of analysis.
Malcure Malware Shield (Removal, Repair, Monitor) before 19.9.7 fails to enforce an authorization check on an AJAX action, allowing an authenticated subsite administrator on a WordPress multisite network to write and delete arbitrary files in the network's shared filesystem, which can lead to remote code execution. The vulnerability requires a multisite installation and an existing privileged account (CVSS PR:H); it is not exploitable on single-site installs or by unauthenticated users, and SSVC records Automatable:no. Publicly available exploit code exists, but no active exploitation is confirmed (CISA KEV absent; SSVC Exploitation:none), and EPSS is low at 0.18% (7th percentile).
Sandbox escape leading to arbitrary host code execution in vm2 (the npm sandbox library, CPE cpe:2.3:a:patriksimek:vm2) affects all versions before 3.12.2 when NodeVM is configured with a custom `require.external` resolver and `context: 'host'`. Because the resolver records the allowed module directory as an unanchored prefix pattern, untrusted guest code can require an allowlisted package (e.g. `foo`) and then require a non-allowlisted sibling sharing that prefix (e.g. `node_modules/foo2/index.js`), whose top-level code is loaded via `hostRequire` in the host process before `vm.readonly` wrapping, yielding code execution outside the sandbox. Exploitation requires the non-default host-passthrough external-resolver deployment plus a prefix-sharing sibling package, but needs no authentication or user interaction (CVSS:4.0 9.5, AT:P/PR:N/UI:N; assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H); no public exploit code was identified at time of analysis and the flaw is not in CISA KEV, though the vendor has published patched commits and version 3.12.2.
Coordinator impersonation in Edgeless Systems Contrast (a confidential-computing runtime for Kubernetes) before version 1.4.1 lets an attacker who can redirect traffic to a rogue Coordinator recover arbitrary secrets of workloads deployed after the attack. The recovering Coordinator fails to verify the seed supplied by the recovering party, so a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled can issue certificates chaining to its own root CA, impersonating a workload owner when the `contrast` CLI `set` call does not compare the returned root CA certificate against the existing one (the CLI's default behavior) or when `verify` is run without comparing against a trusted reference. Exploitation is unauthenticated but conditional - it requires a network-position/man-in-the-middle prerequisite plus a victim workload-owner action - so this is a genuine but conditional integrity and confidentiality flaw rather than a widespread emergency; no public exploit is identified at time of analysis and the issue is not in CISA KEV.
Authentication bypass in the miniOrange OTP Login, Verification and SMS Notifications WordPress plugin (all versions up to and including 5.5.5) allows an unauthenticated remote attacker to log in as any existing administrator account by submitting only a known admin username, an empty password, and the POST parameter mo_wp_login_intent=otp - no password or OTP check is ever performed. Exploitation requires a specific, non-default configuration in which the site administrator has simultaneously enabled WP Login OTP, Login with Only OTP, Allow Users to Login with Username and Password, and Admin OTP Bypass; that prerequisite stack is the primary limiting factor and is why our independent assessment rates the issue AC:H rather than the AC:L assumed by the published 9.8 score, while the impact ceiling (full WordPress site takeover via an administrator session) remains high. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, so risk is real but contingent on the vulnerable option combination being present; the upstream plugin repository shows a code fix commit.
Froxlor hosting control panels before 2.3.12 do not invalidate existing panel sessions, issued API keys, or 2FA 'trust this device' cookies when an account password is changed, so an attacker who already holds one of those authentication artifacts keeps full access to the account even after the victim rotates their password as an incident-response measure. The flaw is a post-compromise persistence issue: it requires a separate, prior theft of a session cookie, API key, or 2FA trust token, making the CVSS 4.0 base score of 8.7 and its AC:L/PR:N framing an overstatement of real-world risk; our independent assessment rates it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, with impact scope depending on whether the affected account is a customer or an admin/reseller. No public exploit code has been identified and the issue is not confirmed actively exploited (not in CISA KEV). A vendor-released patch is available in version 2.3.12.
Second-factor bypass in Froxlor through 2.3.10 allows an attacker who already knows a target administrator's password to defeat the administrator's TOTP protection and obtain a full authenticated admin session. The flaw is rooted in remembered-2FA tokens (panel_2fa_tokens) storing only a bare numeric user ID with no account-type namespace; because customer and administrator IDs are drawn from separate sequences, a remembered-2FA cookie issued to a customer can satisfy the login-time token lookup for an administrator with the same numeric ID, which is not constrained by account type. Exploitation is chained and targeted: it requires prior password compromise, control of a customer account whose ID collides with the target admin, and a live remembered-2FA cookie, so this is not a default-config remote takeover; no public exploit code was identified at time of analysis, and the issue is fixed in 2.3.12 (per the CVSS 4.0 vector, PR:L).
Unauthenticated account takeover of pending invited users in Budibase Server (@budibase/server) versions 3.41.0 through 3.45.0, caused by an authentication bypass in the OIDC/SSO login path. In sso.authenticate, when no existing user matches the incoming SSO subject, the server resolves pending invites using only the IdP-asserted email address, skipping both invite-code validation and the email_verified check (which guards only the existing-account lookup), so anyone who can register at a trusted IdP and claim a victim's invited email - even with email_verified=false - consumes the invite and inherits its privileges, including builder and admin.global roles. Impact scales with the outstanding invite: an admin.global invite yields full tenant compromise (all apps, datasources with production credentials, automations) and the invite is consumed, denying onboarding to the legitimate invitee. Exploitation requires OIDC/SSO configured against a trusted IdP and an unclaimed pending invite matching the asserted email, per the vendor's AT:P attack-requirement modifier; no public exploit code or confirmed active exploitation was identified at time of analysis, and CVSS 4.0 rates this 9.2 with a CVSS 3.1 equivalent of AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
MFA bypass in StoatChat before 0.15.5 allows an authenticated attacker to satisfy the MFA step-up re-authentication challenge for another user's session by presenting an MFA ticket minted from their own account, enabling them to disable the victim's TOTP, view recovery codes, and perform other sensitive account operations without knowing the victim's credentials. Exploitation is conditionally gated: the attacker must hold both a valid StoatChat account (to obtain a legitimate ticket) and an already-stolen victim session token, which the flaw itself does not provide. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released 0.15.5 as the fix.
MFA enforcement in Stoatchat before 0.15.5 can be bypassed by an attacker who already holds the victim's password, because the platform applies rate limiting only per source IP to TOTP challenges and allows a single MFA challenge ticket to be reused across repeated failed attempts. By rotating source addresses, an attacker can guess the TOTP code essentially without an account-level attempt limit and gain full account access; exploitation requires that MFA is enabled on the target account, and no public exploit code has been identified at time of analysis.
Unauthenticated information disclosure in the getgrav/grav-plugin-comments plugin (through 1.2.10) lets a remote attacker retrieve every comment posted to a Grav site in the last 7 days, including each commenter's email address and the absolute server filesystem path of the underlying data file, simply by sending a GET request to /admin/comments/page:<n> (for example page:0.001). The vulnerable admin handler performs its authorization check against isAdmin(), which only signals that the admin service is registered on the current route rather than that the visitor is authenticated, and it emits the JSON response and calls exit() during the plugins stage before the classic Admin plugin can render its login screen. Exploitation requires the site to run the classic Grav Admin plugin with the Comments plugin enabled (the default configuration), and is a genuine but bounded risk: no public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the assessed impact is limited to confidentiality (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), with no write or code-execution capability - the 8.7 CVSS 4.0 score published with the CVE reflects a higher-confidence confidentiality weighting than this assessment supports. The issue is fixed in 1.2.11.
Privilege escalation in Grav CMS 2.0.14 through 2.0.24 allows an authenticated backend operator who already holds the admin.users permission - but not admin.super - to grant super-admin rights to their own account or to a group they belong to via the flex accounts backend. The bypass works because the security guard is resolved against a field's exact blueprint path, so a crafted flat dot-notation key such as access.admin.super evades the rule match and is later reconstructed into a genuine nested value when the object is saved. No public exploit code has been identified at time of analysis, and because the attacker must already possess privileged but non-super backend access, this is an insider or post-compromise escalation vector rather than a remote unauthenticated one - but the resulting super-admin control over configuration, plugin and theme installation, the file manager, and all accounts makes it a genuine, high-value escalation rather than a high-CVSS-but-low-real-risk issue.
Hostname verification bypass in Netty's QUIC client affects versions 4.2.11.Final through 4.2.17.Final when the application supplies a plain javax.net.ssl.X509TrustManager rather than an X509ExtendedTrustManager, allowing an attacker positioned on the network path to present a certificate chain for the wrong hostname that the trust manager still accepts. In practice exploitation requires an active man-in-the-middle position rather than a trivial remote attack, since the attacker must intercept the QUIC connection and hold a valid-but-mis-matched certificate; the CVSS 4.0 score of 8.7 (AV:N/AC:L/PR:N/UI:N) overstates this precondition. No public exploit code was identified at time of analysis, and clients using X509ExtendedTrustManager are not affected; Netty 4.2.18.Final resolves the issue.
HTTP/1-to-HTTP/3 tunnel policy bypass in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.2.Final through 4.2.17.Final) allows a remote, unauthenticated client to desynchronize a CONNECT request so that the tunnel authority forwarded over HTTP/3 is taken from the attacker-supplied Host header rather than the validated HTTP/1 authority-form request-target. A Netty-based proxy or gateway that performs its allow-list, egress, backend-selection, or audit checks against the request-target can therefore be induced to tunnel traffic to an attacker-chosen authority, an integrity-only impact (no confidentiality or availability loss) consistent with the vendor CVSS 4.0 score of 8.7 and the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N. The issue is fixed in 4.2.18.Final; no confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, and exposure is limited to deployments that actually translate inbound HTTP/1 CONNECT requests to HTTP/3.
Authentication bypass in the SiYuan note-taking and knowledge-management publish service affects all releases before v3.8.4: session cookies for the publish feature are issued without the Secure or SameSite attributes and are transmitted over plaintext HTTP, so an on-path attacker can observe the publish-visitor-session-id cookie during a legitimate Basic Auth exchange and replay it against authenticated publish endpoints without knowing the account password. Exploitation requires the publish service to be enabled and protected by Basic Auth, the service to be reachable over cleartext HTTP rather than HTTPS, and the attacker to hold a man-in-the-middle network position (attack requirements: present in the CVSS 4.0 vector); serving the service over TLS removes the exposure entirely. No public exploit code was identified at time of analysis and there is no CISA KEV entry; the independent assessment rates this CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, a confidentiality-only impact, making it a genuine but conditionally exploitable bypass rather than an unconditionally high-risk flaw.
Sensitive-path guard bypass in SiYuan 3.8.0 through 3.8.3 lets an authenticated administrator reach files that the protected-workspace denylist is designed to exclude by invoking recursive MCP file operations against a permitted root: file.grep can return matching lines from non-hidden protected descendants such as conf/conf.json, TLS keys, data/snippets/conf.json, data/templates/, data/.siyuan/publishAccess.json, notebook .siyuan internals, and the kernel log, while file.copy can stage those descendants to an ordinary path for a follow-on file.read and unzip can overwrite them using lexically contained ZIP member names. The defect is an incomplete fix for GHSA-c8r8-95hg-mp34 that was addressed in SiYuan 3.8.4, and no public exploit code was identified at the time of analysis. Because administrative authentication (PR:H) is mandatory and SiYuan is typically a single-user, self-hosted tool where the admin is the sole operator, real-world risk is materially constrained, though prompt injection into the in-app Agent is the practical amplifier since file.grep is globally classified as a safe action and therefore receives no per-call confirmation.
Vertical privilege escalation and account takeover in Capgo (capgo.app) through 12.261.0: an authenticated attacker who already holds the org_admin tier permission org.update_settings can rewrite the provider_id column of a public.sso_providers row over PostgREST and point the organization's email-domain trust anchor at an identity provider they control, after which the server-side SSO merge routine binds the attacker's identity to the legitimate org owner account, nulls that account's password, and deletes its other identities and sessions. The impact is full owner/super_admin takeover plus lockout of the real owner, although exploitation is gated on the target organization having an active SSO provider configured and on the attacker already possessing org_admin in that organization; no public exploit code was identified at time of analysis and there is no CISA KEV entry. The incomplete nature of the fix (a BEFORE UPDATE guard that freezes dns_verified_at, domain, status and enforce_sso but leaves provider_id, metadata_url and attribute_mapping writable under a table-wide ALL grant with only row-scoped RLS) makes this a durable privilege-escalation path rather than a one-off misconfiguration.
Authorization bypass in Flowise through 3.1.4 exposes the BullMQ (Bull-Board) admin dashboard to any authenticated user - including the lowest-privileged member of any tenant - when the server is started with MODE=queue and ENABLE_BULLMQ_DASHBOARD=true outside cloud mode. Because the /admin/queues mount is guarded only by verifyTokenForBullMQDashboard, which validates the JWT but performs no role, permission, or workspace/organization scoping, an attacker can read every queue and job payload instance-wide - chat inputs, overrideConfig objects that may carry credentials and prompts, chatflow.flowData graph definitions with custom function source code, chatIds, files, and the originating orgId/workspaceId - and can invoke write actions such as retry, remove, promote, and clean across tenants. Exposure is configuration-dependent (default single-process and cloud deployments are not affected) and no public exploit code has been identified at time of analysis.
Account takeover in Flowise through 3.1.4 allows unauthenticated attackers to impersonate any existing user by claiming that user's email at any configured SSO provider. This authentication bypass (CWE-287) occurs because the application resolves users solely by email without storing provider or subject identifier bindings, enabling cross-provider or local-password claim of identities. Exploitation requires SSO to be enabled and knowledge of a victim's email, but no public exploit code has been identified at time of analysis.
Authentication bypass in Flowise 3.1.4 and earlier running in Enterprise/platform mode with SSO enabled allows an attacker who can authenticate at any configured SSO provider while asserting a pending invitee's email address as the email claim to hijack that invitation, flipping the target account and its organization membership to ACTIVE without ever possessing the emailed invitation token. Our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L (vendor CVSS 4.0 base 9.2), reflecting full confidentiality and integrity impact with high attack complexity driven by the need for a matching SSO identity; the practical limiting factor is the trust and email-verification behavior of the configured SSO provider, and exploitation is constrained to the invitation's validity window (24 hours by default). No public exploit code has been identified at time of analysis, and at the time of the advisory no patched version was available.
Unauthenticated attackers can create or overwrite arbitrary WordPress posts through the Testimonials Widget plugin's front-end testimonial submission form in versions up to 4.0.4. The missing capability and ownership check (CWE-862) lets any anonymous visitor change post titles, content, and authors without authentication or user interaction, with impact limited to content integrity. Publicly available exploit code exists, but EPSS is low at 0.14% (3rd percentile), SSVC reports no observed exploitation, and CISA KEV does not list the issue.
Authorization bypass in OpenClaw before 2026.7.1 lets an authenticated but non-owner user run the '/mcp set' and '/mcp unset' commands to persist arbitrary stdio MCP server entries, which OpenClaw then executes with its own process privileges the next time it loads its MCP configuration - giving the attacker full impact on host confidentiality, integrity, and availability (assessed CVSS:3.1 base 8.7, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The flaw is a missing-authorization issue (CWE-862) exploitable only where more than one principal shares an OpenClaw instance, with execution deferred to the subsequent config-load event. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and impact is confined to versions prior to 2026.7.1.
OpenClaw deployments before 2026.7.1 contain an authorization-bypass flaw in the browser tool that lets a sandboxed session reach a paired host node's browser actions even when allowHostControl=false is set, so an attacker who can steer sandboxed agent input (e.g., via untrusted content or prompt injection) can inspect or manipulate the connected browser profile and its authenticated state. The issue affects remote, low-privilege, unauthenticated-at-the-network sandbox input paths (CVSS 8.7, vector PR:L/UI:N), and there is no public exploit identified at time of analysis; risk is concentrated in deployments that actually pair a host browser and feed untrusted content into the sandbox.
Authorization bypass in OpenClaw (npm package 'openclaw') before 2026.7.1 lets a low-privilege, write-scoped caller reach browser-control functionality through the node.invoke code path even though the equivalent direct browser.request path correctly enforces administrator scope. The issue only affects Gateway deployments that honor caller identity and narrower operator scopes, and it requires the attacker to already hold a valid write-scoped credential plus access to a connected browser-capable node; deployments using OpenClaw's shared-secret token or password trusted-operator model are not affected. A successful exploit allows the caller to inspect pages, navigate tabs, and interact with browser-visible applications without the configured admin requirement, with realized impact bounded by the target browser profile and its signed-in state; no public exploit code or confirmed active exploitation was identified at time of analysis.
Broken authorization in OpenClaw before version 2026.7.1 lets a non-owner channel sender invoke the Codex computer-use installation command to install arbitrary plugins and spawn MCP (Model Context Protocol) processes with the privileges of the OpenClaw service user. The assessed vector (CVSS 4.0 base 8.7; CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) requires only that the attacker be able to send messages into an OpenClaw channel, with no user interaction from the legitimate owner, yielding full confidentiality, integrity, and availability impact on the host. No public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV); the risk is nonetheless high because the missing check converts ordinary channel participation into remote code execution in the OpenClaw user's context.
Authorization bypass in the npm package `openclaw` (OpenClaw) before version 2026.7.1 allows an already-authorized non-owner channel sender who holds channel command access to approve or deny Claude Code permission prompts that were meant for the owner, causing the pending action to proceed without owner consent. The severity of any given exploitation is bounded by what the specific Claude Code run requested - the attacker can only green-light capabilities the host run had already queued, so impact ranges from low-risk operations up to high-impact host actions depending on context. No public exploit code was identified at time of analysis and the flaw is not confirmed as actively exploited; the vendor-released fix is version 2026.7.1.
Channel read allowlist bypass in the OpenClaw channel plugins @openclaw/msteams, @openclaw/feishu, @openclaw/matrix, and @openclaw/googlechat before 2026.8.1 lets a low-privilege sender or a steered/prompt-injected agent pull messages, reactions, pins, member lists, and related metadata out of channels and rooms that the operator's read policy was intended to exclude. Exploitation is unauthenticated at the network layer but requires an existing low-privilege channel read capability (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), and it only matters where a restrictive read allowlist is actually configured - default open policies expose nothing new. Exposure is further bounded by the permissions held by the connected bot account, and no public exploit code or confirmed active exploitation has been identified at time of analysis; the vendor fixed the issue in 2026.8.1.
Authorization bypass in OpenClaw before 2026.7.1 allows a write-scoped caller in identity-bearing Gateway deployments to spoof another sender's identifier in message.action requests and invoke a channel action under that requester identity, reaching operations the channel adapter would have denied to the real caller. Exploitation requires a valid low-privilege (write-scoped) credential, an authentication mode that honors caller identity (shared-secret token and password callers are explicitly out of scope), and at least one enabled channel action that relies on requester identity; practical impact is bounded by the enabled channel, the action invoked, and the target account's permissions. No public exploit code or CISA KEV confirmation was identified at time of analysis, and the vendor-released fix is version 2026.7.1.
OpenClaw Slack deployments before 2026.8.1 fail to enforce configured sender allowlists inside multi-person (group) direct messages, allowing an authenticated Slack workspace user who was deliberately excluded from the allowlist to invoke the Slack agent and reach every tool and data source that agent has been granted. Because the bypass is confined to group DMs rather than 1:1 conversations, any excluded participant who shares a multi-person DM with the agent can trigger it without victim-side interaction; the practical blast radius depends entirely on the agent's privileges, ranging from data disclosure on a read-only agent to full command/write capability on a more powerful one. The vendor rates this 8.7 (CVSS 4.0, AV:N/AC:L/AT:N/PR:L/UI:N with high confidentiality, integrity and availability impact), an assessment our independent review considers broadly defensible for the mechanics; no public exploit code and no confirmed active exploitation were identified at time of analysis, though EPSS and KEV data were not provided.
Command-execution approval bypass in the OpenClaw agent runtime (npm package 'openclaw') versions 2026.3.22 up to but not including 2026.8.1 lets an attacker piggyback on a previously approved command wrapper to run arbitrary commands with the OpenClaw process's host privileges, without triggering a new approval prompt; the vendor rates this 8.6 and our independent assessment places it at CVSS 3.1 8.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) because exploitation is gated by two preconditions. An authenticated operator must first have allowlisted or permanently approved a specific wrapper invocation, and that wrapper (a transparent shell carrier, or an opaque utility such as a process monitor, tracer, namespace tool, or proxy wrapper) must resolve on the host; a later agent turn can then substitute an arbitrary inner command in the wrapper's arguments and have it executed under the host privileges of the OpenClaw process. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), and the issue is fully remediated by upgrading to 2026.8.1.
Authorization bypass in OpenClaw before 2026.8.1 lets an attacker reuse an already-approved executable with different arguments, so commands execute without a new approval prompt. The root of the flaw is that 'Allow Always' approvals granted for an exact command are persisted on macOS and Linux as path-only grants, meaning any later invocation of that same binary silently inherits the earlier approval. Exploitation is conditionally gated: an operator must first have granted Allow Always for at least one command, and the attacker must then steer the agent into invoking that binary with attacker-chosen arguments (typically via prompt or content injection), which is reflected in the high attack complexity and user-interaction metrics of the assessed vector rather than a pre-auth internet-facing entry point. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.
OpenClaw before 2026.8.1 fails to enforce per-chat tool policies for Codex app-server runtime tools, allowing an authenticated participant (PR:L) in a lower-trust conversation to bypass a tools.allow allowlist and reach native shell, process, file, and patch tools. The vendor-assigned CVSS 4.0 score is 8.7, and the practical impact depends on the Codex runtime's host permissions and sandbox configuration; the issue is fixed in 2026.8.1. No public exploit identified at time of analysis.
Local file disclosure in OpenClaw (npm package 'openclaw') before 2026.8.1 allows an authenticated, already-admitted requester to read arbitrary known local host files even when that sender's identity has been explicitly denied filesystem read tools through the global or per-agent toolsBySender policy. The bypass occurs because outbound attachment handling - via a final-response media directive or a message attachment - does not re-apply the originating sender's policy, so a denied sender can still have a known local file read and returned to an admitted requester whose agent turn never included the read tool. Exploitation requires the attacker to already be admitted to the agent, to know or derive a useful host path, and to reach a delivery flow that accepts local attachments; impact is read-only disclosure of file contents with no integrity or availability effect, and no public exploit code has been identified at time of analysis.
Privilege escalation in the OpenClaw npm package (versions >= 2026.4.5 and < 2026.8.1) allows a restricted external sender to have its session-derived text persisted into shared session memory and later replayed to an unattended background 'dreaming' agent that holds broader file and command privileges, producing actions beyond the authority of the original turn. The flaw is only reachable in deployments where session-memory capture and the dreaming agent are both enabled and the background agent is provisioned with more capability than the originating turn, and the exploit chain additionally depends on the content being selected for later processing and then actually followed by the model. No public exploit identified at time of analysis; vendor has released a fix in OpenClaw 2026.8.1, and the vendor-assigned CVSS 4.0 score is 7.7.
Privilege escalation and privilege retention in InvoicePlane prior to 1.7.2 allow a previously-authenticated administrator whose account was downgraded or deactivated by another administrator to keep operating with administrative rights through a stale session. Because Admin_Controller trusts the user_type value cached in the session at login rather than re-reading ip_users.user_type, the downgraded user's live session continues to authorize admin requests, and the attacker can then call Users::form() to write user_type back to 1, making the restored admin role persistent in the database. Exploitation is limited to multi-administrator deployments where a role change occurs while the target session stays alive; it requires prior high-privilege access and is not reachable by an unauthenticated or ordinary low-privilege user, and no public exploit code or active exploitation has been identified at time of analysis. The vendor-released fix is InvoicePlane 1.7.2.
Unauthenticated configuration tampering in Apache Roller 6.1.5 lets any remote attacker persistently rewrite the site-global frontpage weblog selection on a default installation, because the installation-time setup action remains anonymously reachable after setup completes and persists the value without any authorization check. Impact is bounded rather than severe: only one site-global setting is altered, no data is disclosed (C:N), and a global administrator can restore the setting afterward, which is why our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L rather than the submitted 8.2 high with I:H/A:L. The attack is a single unauthenticated HTTP request with no user interaction, so exposure is broad wherever 6.1.5 is internet-facing; exploitation status is no public exploit identified at time of analysis, and the issue is not tied to any optional feature or non-default configuration.
Replay of a captured WSSE digest authentication header against Apache Roller 6.1.5 allows an attacker to assume the victim's AtomPub authority - publishing, editing, and deleting blog content under that identity - without ever knowing the underlying password. The assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L, 7.7) rates it as remotely reachable without valid credentials, but real-world exposure is tightly gated: the AtomPub API must be explicitly enabled (it ships off by default), WSSE must be the configured AtomPub authentication method, the install must use plaintext-compatible password storage, and the attacker must first be able to observe a legitimate user's header in transit, which is what drives the High attack complexity. Only version 6.1.5 is affected; 6.1.6 removes WSSE as an AtomPub authentication option, and no public exploit code has been identified at time of analysis (the issue is not in CISA KEV, so there is no confirmation of active exploitation).
Incorrect authorization in the OAuth 1.0a authorization endpoint of Apache Roller 6.1.5 allows an unauthenticated remote attacker to bind an outstanding request token to an arbitrary user account - including an administrator - by submitting an unsigned authorization request that supplies the target identity directly instead of relying on the logged-in session. Exploitation is constrained: it requires an installation that has configured a non-default OAuth 1.0a site-wide consumer, plus knowledge of one of that consumer's outstanding (issued but unconsumed) request tokens, which is the basis for the high attack-complexity rating despite the critical 9.0 CVSS 3.1 score. Successful abuse yields administrator-level API access to the blog server, so confidentiality and integrity impact are high (the independent assessment scores availability impact as none); no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released a fix in Apache Roller 6.1.6.
Missing per-weblog authorization in Apache Roller 6.1.5 allows any authenticated user to read, modify, or delete weblog content owned by other weblogs via the legacy XML-RPC Blogger and MetaWeblog APIs, which authenticate the caller but do not check the caller's permission on the affected weblog or entry. Exploitation requires an authenticated account and the non-default global XML-RPC feature to be enabled, although the per-weblog API flag defaults to on for UI-created weblogs, and impact is confined to weblog content rather than the host. No public exploit identified at time of analysis, and while the NVD-style CVSS 3.1 score is 9.9 (critical) with vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, that figure conflicts with the vendor's Moderate rating and the stated constraints.
The AetherBrowser API server shipped with SCBE-AETHERMOORE versions 4.0.2 through 4.2.0 exposes the POST /api/ops/check-email endpoint with no authentication check whatsoever, letting any remote, unauthenticated attacker invoke the email_reader.py subprocess, which logs into configured ProtonMail or Gmail accounts over IMAP and returns email metadata (sender, subject, and body snippets) in the JSON response. The server listens on 0.0.0.0:8100 by default and sets CORS allow_origins=["*"], so the endpoint is reachable from any network host and callable from any browser origin, though meaningful mailbox disclosure requires that IMAP credentials have actually been configured for the reader. Version 4.2.1 resolves the missing authentication (CWE-306); no public exploit code has been identified at time of analysis.
Source-IP spoofing in Zoraxy 3.2.3 through 3.3.4 lets unauthenticated attackers who reach the service over IPv6 forge X-Forwarded-For and X-Original-IP values, so IP-based access controls enforced by Zoraxy's SSO forward-auth provider see a trusted client address and grant access (CWE-290). The 9.1 CVSS 4.0 severity reflects fully unauthenticated remote exploitation (PR:N), but our independent assessment (CVSS:3.1/AV:N/AC:H/PR:N/UI:N) rates the real-world risk lower because exploitation requires IPv6 connectivity and a deployment that actually relies on forward-auth IP allowlisting as a security boundary, so IPv4-only or non-IP-gated instances are not exploitable. No public exploit code was identified at time of analysis and there is no KEV entry, though a vendor patch is available.
Unauthenticated information exposure in Ciena Navigator Network Control Suite (NCS) allows remote attackers with network access to subscribe to an event-streaming API and read potentially sensitive data. The flaw (CWE-306 missing authentication) affects numerous NCS releases from 7.2 through 10.0 and their patch levels, with a CVSS 3.1 base score of 7.5 due to high confidentiality impact and no integrity or availability impact. No public exploit identified at time of analysis.
Account takeover in GLPI is achievable by an authenticated technician-level user who supplies an 'authtype' value in a user-update call to the REST API, allowing them to silently change another account's authentication method - including that of a super-administrator. The issue affects GLPI from version 0.70 up to (but not including) 10.0.26 and 11.0.x before 11.0.8, and the dangerous takeover path is scoped to instances using the legacy REST API interface or SSO/external logins, since the attacker switches the victim onto an authentication method they control. Successful exploitation requires a valid authenticated account with rights to update other users but lacking the UPDATEAUTHENT right, plus the non-default legacy-API or SSO configuration; no public exploit code or confirmed active exploitation was identified at time of analysis, though the CVSS 4.0 base score is 7.5.
S/MIME signature spoofing in Zammad before 7.1.2 lets a remote, unauthenticated sender forge email that Zammad displays with the same 'validly signed' indicator as a genuine message, by presenting a self-made certificate whose subject name matches a certificate already stored for a real, previously trusted sender - no access to that sender's private key is required. Exploitation requires inbound S/MIME signature verification to be enabled on the target instance, a certificate to already exist for the impersonated sender, and a human (agent/user) to view and act on the forged ticket, so impact is confined to integrity/spoofing with no data disclosure or service disruption. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; a vendor fix exists in 7.1.2, and the flaw is genuine rather than inflated CVSS.
Zammad's SSO auto-linking logic can be abused to take over any existing local account, including agent and administrator accounts, because it binds an incoming third-party identity to a local user purely by matching the email address the identity provider reports. An unauthenticated remote attacker only needs to control one identity at any provider configured on the target instance - with Zammad's default multi-tenant Microsoft 365 /common app registration, any Azure AD tenant qualifies - set that identity's email to the victim's address, then authenticate and be logged in as that victim without ever knowing their local password. Exploitation requires the 'Automatic account link on initial logon' setting to be enabled and at least one SSO provider configured; no public exploit code has been identified at time of analysis and the issue is confirmed fixed in Zammad 7.1.2.
X-SpringBoot through 6.0 allows remote unauthenticated attackers to hijack user accounts by abusing unauthenticated endpoints that return login verification codes in HTTP responses, enabling authentication as any victim whose mobile number or email is known. Publicly available exploit code exists, and the vulnerability is not confirmed actively exploited (not in CISA KEV). Affected users are those running X-SpringBoot versions 0 through 6.0 with network-exposed login endpoints.
Inbound PGP signature verification in Zammad is bypassed because the result of the gpg verification call was discarded, so the helpdesk marks every multipart/signed PGP message as 'Good signature' regardless of whether the signature is valid, invalid, or absent. Any sender can therefore tamper with the body of a signed email - or supply a fabricated or mismatched signature - and remote attackers (CVSS 4.0 vector shows PR:N, unauthenticated) can have the altered content displayed to agents and users as cryptographically verified; exploitation requires the recipient to view the affected article (UI:P) and impacts integrity only (VI:H, no confidentiality or availability impact). All inbound PGP-signed email handled while PGP integration is enabled is affected prior to 7.0.2, and at time of analysis no public exploit code or confirmed active exploitation has been identified; the practical risk is a moderate authenticity/trust defect rather than an urgent one, since it enables content forgery and misleading signature indicators but does not by itself grant code execution or data access.
Bludit CMS through version 3.22.0 allows authenticated users with Author or Editor roles to read private drafts and scheduled posts belonging to any other user, including administrators, by sending a crafted request to the content-get-list AJAX endpoint. This missing authorization vulnerability (CWE-862) is network-reachable, requires low-privilege authentication, and results in high confidentiality impact with no integrity or availability effects. No public exploit code or active exploitation has been identified at time of analysis.
Internal article attachments in Zammad helpdesk before 7.0.2 can be pulled down by the very customer who owns the ticket, because the attachment download API authorizes only against the parent ticket and never against the article itself (CWE-863). Any authenticated customer with normal view access to a ticket (CVSS v4.0 PR:L, AV:N) can therefore retrieve files attached to internal notes that the article listing API deliberately withholds, giving a confidentiality-only impact with no integrity, availability, or scope change. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV; the independent assessment characterizes this as a genuine but bounded broken-authorization flaw rather than an inflated high-CVSS issue, and a vendor patch is available in 7.0.2.
Zammad versions prior to 7.0.2 contain an insecure direct object reference (CWE-639) in the knowledge base answer attachment endpoints, allowing an authenticated user with limited knowledge-base permissions to create, delete, or clone attachments on answers outside their assigned access scope. The flaw stems from controller policies that authorized actions broadly by role rather than validating the specific answer object, so an agent (or similarly scoped user) could reach attachments they should not be able to modify or even see. The vendor fixed the issue in 7.0.2 by delegating authorization to the per-answer policy; no public exploit code was identified at time of analysis, and the impact is confined to the confidentiality and integrity of knowledge base attachments rather than code execution or availability.
A tenant isolation bypass in BerriAI LiteLLM versions before 1.101.0-rc.1 lets an authenticated holder of a valid virtual key read other tenants' entries from the semantic cache and, in the worst case, have attacker-supplied tool calls executed under a victim's credentials. The flaw stems from an inconsistency in how the cache layer derives the tenant scope versus the metadata variable name, so semantically similar prompts sent to routes such as /v1/responses and /bedrock/* can collide with and return another tenant's cached response - potentially exposing PII, financial data, or source code. Exploitation requires a multi-tenant deployment with semantic caching enabled and a sufficiently similar prompt to hit the victim's cache entry, and it is rated CVSS 8.7 with a vendor patch already released (commit 16db51e2, fixed in v1.101.0-rc.1); no public exploit code has been identified at time of analysis and the CVE is not in CISA KEV.
An authenticated guest with an active booking could unlock rooms other than their own in Akia's keyless entry cloud service by tampering with the client-supplied room or door identifier, because the unlock action was not authorized server-side against that guest's booking-resulting in unauthorized physical access to guest rooms at the affected property. The independent assessment rates this as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N and notes the attack is remote but the impact is local to a single property. Akia reportedly remediated the service server-side as of September 19, 2026; no public exploit code or CISA KEV confirmation was identified at time of analysis.
Unauthenticated attackers can enumerate private and draft galleries and retrieve the original private image bytes from any WordPress site running the Modula Image Gallery - Photo Grid & Video Gallery plugin in versions up to and including 3.0.1. The plugin's Modula_Meta::add_metas() method is hooked to wp_head on every frontend request and builds Open Graph/Twitter meta tags from whatever post ID is supplied in the modula_gallery_id GET parameter, without verifying the gallery's post_status or the requester's read capability, so the response leaks the private gallery item's title, description, dimensions and original upload URL. Exploitation is remote and unauthenticated with no user interaction (CVSS 3.1 base 7.5, confidentiality-only impact), and gallery post IDs are sequential, making enumeration trivial; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Arbitrary file deletion in the Modula Image Gallery - Photo Grid & Video Gallery WordPress plugin, affecting all versions through 3.0.2, allows authenticated attackers with Author-level privileges or higher to delete arbitrary files on the underlying server by supplying a crafted file path to the upload_image function. The root cause is missing authorization (CWE-862) compounded by insufficient path validation; the plugin's restriction to wp-content/uploads does not act as an ownership boundary because every user attachment file resides within that tree, and Authors trivially satisfy the edit_post check on galleries they own. The vulnerability carries a CVSS 3.1 base score of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H), reflecting network reachability, low complexity, and high integrity and availability impact, with no confidentiality impact; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Unauthenticated attackers can exploit an insecure direct object reference in the Bookly appointment-booking plugin for WordPress (all versions up to and including 28.2) to enumerate sequential order IDs and disclose other customers' secret order tokens, retrieve appointment and calendar details, and permanently delete non-completed bookings. The chain requires only a reachable public booking form and the plugin's standard AJAX endpoints; no authentication, user interaction, or non-default configuration is needed, which is why the assessed severity remains high (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H) despite the confidentiality impact being narrower than full data compromise. At time of analysis there is no public exploit code and no confirmed active exploitation (no CISA KEV listing), but the sequential-ID prerequisite is trivially satisfied on typical installations, making opportunistic abuse realistic.
Permanent deletion of arbitrary WordPress Media Library attachments - including administrator-owned product images, logos and documents - is possible in the Customer Reviews for WooCommerce plugin through version 5.120.0, because a missing authorization check (CWE-862) in the review-submission handler lets an unauthenticated remote attacker inject arbitrary attachment IDs into a review that is later trashed and purged through the normal moderation lifecycle. Exploitation depends on a live public review-form link (a 13-hex formId that the store distributes to customers by e-mail), which exposes the nonce needed to reach the handler without any WordPress account or session, and the impact is integrity/availability only - there is no confidentiality impact (C:N). Wordfence rates this CVSS 3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H); no public exploit identified at time of analysis.
Incorrect authorization in phpIPAM's REST API (api/controllers/User.php) allows an attacker with API access to retrieve privileged user records by supplying the special identifiers id='admins' or id='all', bypassing intended access controls. Affected versions are those prior to 1.8.3, which includes a security fix for insecure direct object references. While the CVE lists a CVSS score of 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), the independent assessment indicates the flaw more realistically requires a valid API token (PR:L) and has no scope change (S:U); no public exploit code has been identified at time of analysis.
Session fixation in the HTTP management interface of Apache Qpid Broker-J through 10.1.0 lets remote, unauthenticated attackers hijack an administrator's authenticated management session by reusing a session identifier that is retained across successful authentication, yielding full confidentiality, integrity, and availability impact (C:H/I:H/A:H) over the broker's management functions. Exploitation requires the HTTP management interface to be reachable by the attacker and, critically, requires a legitimate management user - typically an administrator - to authenticate using a session identifier the attacker has planted, fixed, or otherwise obtained before login, so the assessed vector is AV:N/AC:H/PR:N/UI:R rather than the NVD-published 9.8 CRITICAL (AC:L/UI:N), which is inconsistent with the session-fixation class. There is no public exploit identified at time of analysis, and brokers are only exposed where management access is not otherwise restricted; upgrading to 10.1.1 addresses the flaw.
Gerrit Code Review 2.16.0-3.12.9, 3.13.0-3.13.8, and 3.14.0-3.14.2 mishandle project-name normalization, allowing an authenticated user (or an unauthenticated user when the repository was previously public) to keep reading private repository content and to durably restore revoked project-owner administrative privileges. Requests that reference a project with repeated terminal .git suffixes (for example project.git.git) are cached under a different key than the canonical project, so revoking read access or removing owner rules on the canonical name never evicts the stale alias ProjectState during the ProjectCache validity window, permitting reads of newly created private commits and writes to refs/meta/config. No public exploit code has been identified at time of analysis; exploitation requires the attacker to have previously held access to the project and to act before the stale cache entry would naturally expire.
Hard-coded root credentials in Botslab G980H dash camera firmware allow anyone who can reach the device's UART/serial interface to obtain full root access, because the password is embedded in the firmware and cannot be changed, rotated, or disabled by the user. Exploitation is physically gated: it requires hands-on access to the camera plus a serial connection, and per the assessed vector (CVSS:3.1 AV:P/AC:L/PR:N/UI:N, CVSS:4.0 base 7.0) there is no prior-privilege or user-interaction barrier once that physical connection is made, while remote or network exploitation is not possible. There is no CISA KEV listing and no public exploit identified at time of analysis, so the practical risk is limited to attackers with device custody or those who obtain a firmware image, in which case the exposed credential grants complete control of the device (C:H/I:H/A:H).
Taskview Community before 1.56.0 ships its OAuth 2.0 Dynamic Client Registration endpoint enabled by default and reachable without authentication, letting any remote unauthenticated attacker register a rogue OAuth client and obtain a working client_id and client_secret. The attacker then distributes a crafted authorization link that redirects to an attacker-controlled URI, and once the victim approves the consent screen the captured authorization code is exchanged for an access token granting full API access to that victim's account data. No public exploit identified at time of analysis, but with a CVSS 4.0 score of 8.5 and high confidentiality and integrity impact this is a high-priority account-takeover flaw; because exploitation depends on victim interaction it is delivered through phishing-style social engineering rather than a silent compromise.
Physical access to the Botslab G980H dash camera's UART interface grants an unauthenticated root shell and exposes the device's WiFi password. The root account requires no password, allowing an attacker with hands-on hardware access to obtain full control and recover network credentials. No public exploit code or active exploitation has been identified, and the CVSS 4.0 base score is 7.0 with a physical attack vector.
Improper firmware authenticity verification in the Botslab G980H dash camera allows an attacker who can intercept the device's firmware download or supply a crafted update package to install modified firmware and execute unauthorized code on the device. The update process fetches firmware over an unprotected connection and validates only an integrity value delivered alongside the payload rather than a trusted cryptographic signature, so anyone who controls the delivered bytes and recomputes that value defeats the check. The assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) rates this as high severity but with a harder attack path than the vendor-published CVSS 4.0 score of 9.2 suggests, since the attacker needs either an on-path network position between camera and update source or authenticated update-submission access; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the intelligence signals around this advisory remain thin.
Predictable session identifier generation in the Botslab G980H dash camera allows an unauthenticated attacker on the same adjacent network to enumerate or guess a valid session ID and use it to bypass the device's authorization controls, gaining high-impact read/write access to camera functionality. Exploitation is constrained rather than trivial: the attacker must already be on the same local/link-layer network as the camera and must time the attempt to coincide with a legitimate active session, and the supplied CVSS 4.0 vector reflects that prerequisite via AT:P alongside AV:A, PR:N and UI:N. There is no remote-internet attack path, so this is best characterized as a genuine but not high-priority weakness; no public exploit code has been identified at time of analysis and no CISA KEV listing or EPSS data accompanies this report.
Session-hijacking authorization bypass in Botslab G980H dash camera firmware lets an attacker on the adjacent network (the camera's Wi-Fi/link-local segment) reach privileged, session-gated commands by presenting a session identifier that belongs to a different, already-authenticated client, because the firmware never binds session state to the connection that created it (CWE-863). Successful abuse gives high impact to confidentiality, integrity and availability of the camera itself - full compromise of the device's privileged functionality - though exploitation is not opportunistic: an attacker must be within adjacent-network range and a legitimate client must already hold a live authenticated session whose identifier can be obtained or replayed. The vendor CVSS 4.0 base score is 8.7 (High, AV:A/AC:L/PR:N/UI:N/VC:H/VI:H/VA:H), while our independent CVSS 3.1 assessment rates it AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H to reflect the session-hijack precondition; no public exploit code and no confirmed active exploitation (no CISA KEV listing) were identified at time of analysis.
Missing authorization in the ServiceNow AI Platform lets unauthenticated remote attackers, under certain vendor-undisclosed instance conditions, read instance data beyond the intended scope and escalate privileges. ServiceNow has remediated the flaw on its hosted instances and distributed the fix to partners and self-hosted customers, but no public exploit code or active exploitation has been reported and no EPSS score was supplied with the source data. The vendor CVSS 4.0 rating is Critical (9.3), while the independent assessment is lower and treats exploitation as conditional, so unpatched self-hosted or partner-managed instances should still be prioritized given the data-exposure and privilege-escalation potential.
Improper authorization in Dell Rugged Control Center (RCC) builds prior to 5.2.206 allows a low-privileged local user to escalate privileges on an affected rugged Dell endpoint. The vendor rates this CVSS 8.1 with a local attack vector, low privileges required, scope change, and high integrity and availability impact (AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:H), meaning an attacker or malware must already hold a foothold on the specific rugged device - it is not remotely or unauthenticated exploitable. No public exploit code or confirmed active exploitation was identified at time of analysis, and Dell has released a fixed build (5.2.206) via advisory DSA-2026-410.
Unauthenticated data disclosure in ServiceNow AI Platform instances stems from an authorization bypass (CVSS 8.7) that lets remote attackers read records they are not entitled to access. ServiceNow has already remediated its hosted instances, so exposure now concentrates on self-hosted and partner-managed deployments that have not applied the KB3159623 update or upgraded to a patched release. No public exploit code has been identified and no confirmed active exploitation (CISA KEV) has been reported, yet this remains a genuine priority for ServiceNow customers even in the absence of exploitation telemetry.
Missing authentication for a critical device function in Dell ThinOS 10 (all versions prior to SecurityAddon_2605.10.2766_T10) allows an unauthenticated remote attacker who can reach the exposed function to gain unauthorized access to it, reflected in a CVSS:3.1 base score of 8.6 under the vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L, where the high integrity impact dominates and confidentiality and availability effects are limited. No public exploit code and no confirmed active exploitation were identified at time of analysis, so this is a genuine priority signal rather than a confirmed-exploited emergency. The main practical constraint on exploitation is network reachability: ThinOS endpoints are typically deployed inside enterprise/VDI network segments rather than exposed to the public internet, so meaningful risk arises when an attacker already has a foothold on a segment from which the affected service can be reached.
Unauthenticated network requests against unpatched ServiceNow AI Platform instances can create, modify, or delete instance data beyond what was intended, per a vendor-remediated improper access control flaw rated 8.7 under CVSS 4.0 (independent assessment: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). Impact is integrity-only - no confidentiality or availability loss is described - and ServiceNow scopes exploitation to "certain circumstances," so the flaw is not universally reachable on every default deployment and undisclosed configuration preconditions appear to gate it. ServiceNow patched hosted instances in August 2026 and shipped the update to partners and self-hosted customers, leaving residual exposure concentrated in self-hosted and partner-managed instances that have not yet applied it. No public exploit code and no confirmed active exploitation (no CISA KEV listing) were identified at time of analysis.
Improper TLS certificate validation in Dell ThinOS 10 endpoints running SecurityAddon builds prior to 2605.10.2766_T10 lets an adjacent-network attacker bypass a protection mechanism and gain unauthorized access to client communications and credentials. The flaw is rated CVSS 8.3 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L), meaning no authentication or user interaction is required, but the attacker must already sit on the same Layer-2 segment, VLAN, or Wi-Fi network as the thin client to position themselves for a machine-in-the-middle interception. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, so this is a genuine elevated-priority issue rather than an emergency - the practical risk is driven by how flat and trusted the thin-client network segment is.
Authorization bypass in the ServiceNow AI Platform lets any authenticated user with an ordinary low-privilege account read records and data they are not entitled to, and because the flaw crosses a security scope boundary it can also enable further unintended access on resources beyond the vulnerable component. Exploitation is network-reachable and requires only a valid low-privilege session - no elevated role, no user interaction, and no special client configuration - so the practical attack path is a compromised, internal, or low-tier tenant account rather than an anonymous attacker. ServiceNow has already remediated hosted instances and distributed the update to partners and self-hosted customers, and the vendor states it is not aware of malicious exploitation; no public exploit code or CISA KEV entry was identified at time of analysis, leaving unpatched self-hosted and partner deployments as the primary exposure.
Unauthenticated remote code execution in Honeywell PD45 Industrial Printer firmware F10.19.010040 lets any network-reachable attacker upload attacker-controlled files through the web management interface and execute them as malicious files and commands. The CVSS 3.1 base score of 9.8 (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H) reflects the complete absence of authentication or user interaction required, consistent with CWE-306 missing authentication for a critical function, so a single unauthenticated HTTP request path is enough to gain code execution on the device. Honeywell has released fixed firmware F10.22.030745; no public exploit code has been identified at time of analysis, but exposure is constrained mainly by the fact that these industrial printers typically sit on internal warehouse or manufacturing networks rather than the public internet, meaning an attacker usually needs an existing network foothold or adjacent access first.
Quick Facts
- Typical Severity
- CRITICAL
- Category
- auth
- Total CVEs
- 42440