Authentication Bypass

Continue CLI through 1.5.47 can be tricked into executing commands outside its approved Bash prefix rules when an unauthenticated attacker injects instructions into repository files or fetched web pages that the agent processes; the agent then chains an unapproved command after ;, &&, or |, resulting in code execution as the user. Exploitation requires that the operator has configured at least one permissive Bash allow rule, that the agent is pointed at attacker-controlled content, and that the victim runs the agent against that content, so default installations without Bash approval rules are not exposed. No public exploit identified at time of analysis; the issue is rated CVSS 7.7 and is a genuine, moderately high-priority concern for users running the Continue CLI agent on untrusted inputs.

Navigation allowlist bypass in EdgeEver Desktop versions 1.6.26 through 1.112.0 allows an attacker who can get crafted content rendered in the app (for example a note-template preview) to load an arbitrary origin into the main window and capture the edgeeverDesktop bridge, including the session token, sidecar RPC, and ACP channels. The flaw is an incorrect-authorization issue (CWE-863) in which the will-navigate handler trusts a string-prefix match, so a URL that places the trusted dev-server prefix in the userinfo portion (e.g. https://devserver@attacker.tld) is accepted while the real origin is attacker-controlled. Exploitation requires a low-privileged authenticated foothold to plant the content and user interaction for the victim to open or preview it, and no public exploit code has been identified at time of analysis; the source CVSS 4.0 vector scores 8.4 (High), driven by high confidentiality and integrity impact that can escalate to command execution through ACP adapters.

Nginx UI deployments that use Casdoor OAuth/SSO for authentication can issue a valid application session for an attacker-chosen identity on versions prior to 2.4.1, because the OAuth 'state' value is a fixed constant (the configured Casdoor application name) and the callback never binds it to the browser session that started the login. An unauthenticated attacker who persuades a victim to open a crafted Casdoor authorization link can have the victim's browser complete the attacker-controlled authorization flow, after which the callback mints an Nginx UI session for the identity returned by that authorization code - yielding high confidentiality impact with limited integrity impact (CVSS 3.1 7.1, AV:N/AC:L/PR:N/UI:R). The flaw is conditionally gated: it only applies to instances with Casdoor OAuth configured and requires victim interaction, so it is a genuine authentication-bypass issue rather than a universally exploitable one; no public exploit code was identified at time of analysis, and a vendor-released patch in version 2.4.1 is available.

Privilege escalation in Nginx UI lets any holder of an authenticated account take over the built-in administrator by changing the admin's password through POST /api/users/:id, which omits the RequireSecureSession step-up that the self-service password-change path enforces. Successful abuse silently invalidates the legitimate administrator's existing tokens, and the attacker can then authenticate as the administrator with full control over the Nginx configuration managed by the UI. All releases prior to 2.4.1 are affected; the vendor-released fix is version 2.4.1, and no public exploit code has been identified at time of analysis, though the assessed CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects complete loss of confidentiality, integrity, and availability. The practical exposure is gated by the need for a pre-existing low-privilege account, so multi-user deployments are directly at risk while single-admin instances that never provision secondary users have no untrusted principal to abuse.

Broken object-level authorization in Telegram-Stremio through 5.1.0 lets an attacker who holds a valid low-privilege API token read arbitrary Telegram chat messages - including private channels, groups, and Saved Messages - by setting a global routing flag in the stream_handler endpoint and enumerating sequential, unsigned msg_id values that the application only obfuscates with its encode_string/decode_string routines. The separate thumb_handler endpoint performs no token validation at all, so thumbnails from those same chats are disclosed without any authentication, widening the exposure beyond the token-gated path. Publicly available exploit code exists (a public PoC gist) and VulnCheck has published an advisory, but no CISA KEV entry confirms active exploitation and no vendor-released patch was identified at time of analysis; the assessed impact is confidentiality-only (high), with no integrity or availability effect.

Nginx UI versions prior to 2.4.1 fail to enforce the RequireSecureSession step-up check on multiple authenticated mutation endpoints, so an attacker who already holds a valid session token for an OTP- or passkey-enabled account can create or modify automatic backups, DNS credentials and records, certificates and ACME users, Nginx control settings, and site or stream automation without ever supplying a fresh X-Secure-Session-ID. The flaw is a missing-authorization-check class issue (CWE-862) rated CVSS 3.1 base 8.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H): it requires a stolen or otherwise obtained authenticated session (PR:L) but no user interaction, giving high integrity and availability impact. No public exploit code was identified at time of analysis and there is no indication the issue is being actively exploited; the upstream fix is available in release 2.4.1.

Unauthenticated remote attackers can gain full administrative control of the HAProxy Data Plane API - and through it the managed HAProxy load balancer - in Community and Enterprise Edition releases 2.2.0 through 3.4.3 when a specific mTLS topology is deployed. When a TLS Certificate Authority (tls_ca) and a numeric TLS port (tls_port) are configured, Server.ConfigureAPI() sets a process-global flag that disables HTTP Basic authentication on a request handler shared concurrently by HTTP, HTTPS, and UNIX-domain-socket listeners, while mutual-TLS client-certificate verification is only enforced on the HTTPS path; every other active listener therefore fails open. An attacker who can reach a plain HTTP or UNIX management endpoint can read cleartext HAProxy configuration data and replace the managed configuration via the raw configuration endpoint; no public exploit code has been identified at time of analysis, and the vendor has released fixed versions 3.4.4, 3.3.9, 3.2.17, 3.0.25 and 2.9.29 (plus EE backports).

Unauthenticated remote agent enumeration and invocation in PraisonAI's AgentTeam.launch() / Agents.launch() HTTP server lets any client that can reach the listening port list deployed agents and trigger agent.chat() calls, burning model resources, reaching connected private context, and firing agent tools and workflow side effects. The affected artifact is the Python package praisonaiagents before 1.6.59, whose FastAPI server binds to 0.0.0.0 by default and accepts requests with no Authorization header - or even with an obviously wrong bearer token. Vendor-released patch: praisonaiagents 1.6.59 (PraisonAI v4.6.59); no public exploit identified at time of analysis, and the practical limiting factor is deployment: the routes are only remotely reachable if launch() is actually started and network-exposed rather than bound to localhost or placed behind an authenticating proxy.

Authenticated users of IBM Db2 11.5.0 through 11.5.9 and 12.1.0 through 12.1.5 for Linux, UNIX and Windows (including DB2 Connect Server) can obtain sensitive information they are not authorized to see by issuing the CREATE WRAPPER command, which is improperly authorized. The vulnerability is rated CVSS 3.1 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), so it requires a remote attacker to already hold valid Db2 credentials and the privilege to invoke CREATE WRAPPER; there is no integrity or availability impact, making this primarily an insider or compromised-credential risk rather than an unauthenticated breach vector. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited, but fixed code is available from IBM and should be applied, particularly in environments where federation features are enabled.

Temporal Server's multi-cluster namespace replication logic fails to reject inbound replication tasks targeting local (non-global) namespaces, letting a party that operates or compromises a registered peer cluster overwrite local namespace state - including the built-in temporal-system namespace - without any credential on the receiving cluster. The receiving side only checks that the supplied namespace identifier matches an existing record, then rewrites state, description, owner, retention, archival settings, cluster list, and (when the task carries a higher failover version) the active cluster; an attacker can therefore mark a namespace Deprecated, make the peer its active cluster, and shorten retention so new Workflow starts fail. Exploitation is gated on a multi-cluster deployment with at least one remote cluster registered with connection enabled (a single-cluster or no-remote-cluster setup is not exposed), and the assessed CVSS:3.1 vector is AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:L - high privileges are required in the sense of holding the trusted peer position, which is the dominant real-world constraint. No public exploit code has been identified at time of analysis and there is no CISA KEV listing; vendor-released fixes exist in Temporal Server v1.30.8, v1.31.4, and v1.32.1.

Improper authorization in obsidian-tc prior to 1.3.1 lets any holder of a valid JWT reach beyond its own vault and read, write, or delete the contents of every other configured vault on the same HTTP server. The flaw affects CWE-639-style trust in a caller-controlled key: tool dispatch never compares the caller-supplied input.vault value against the vault bound to the caller, the JWT carries no vault claim, and the folder ACL is a single global instance, so roughly 90 vault-scoped tools resolve an attacker-named vault id under that shared ACL. Exploitation requires the HTTP transport with more than one vault configured and a valid token (authenticated, PR:L); the trusted stdio transport is unaffected and single-vault deployments have no second vault to pivot to, but cross-tenant confidentiality, integrity, and availability are all fully compromised when those conditions hold - no public exploit code has been identified at time of analysis.

Kerberos authentication service impersonation in Progress MarkLogic Server 12.x before 12.1.0 and 11.x before 11.3.7 lets an unauthenticated, suitably positioned network attacker impersonate trusted authentication infrastructure, potentially resulting in unauthorized access to or modification of protected data. Exploitation is conditional: it requires a deployment configured with Kerberos-backed password-based (external) authentication and an attacker holding a privileged on-path network position between the server and the Kerberos KDC, which is why CVSS rates attack complexity as high despite no required user interaction or prior authentication. No public exploit code or confirmed active exploitation has been identified at time of analysis.

Insufficient access controls in Progress MarkLogic Server 12.x (before 12.1.0) and 11.x (before 11.3.7) allow a remote, authenticated attacker holding only limited management privileges to read security-sensitive information, which can then be used to reach protected resources outside that account's intended scope. The CVE carries a 7.7 score with a scope-changing vector (S:C) because the confidentiality impact crosses a privilege boundary, but exploitation is gated on the attacker already possessing a valid low-privilege management account (PR:L), and no user interaction is required. No public exploit code and no CISA KEV listing were identified at time of analysis, so real-world exposure concentrates in multi-tenant or role-segmented installations, or as a lateral-movement step after an initial account compromise.

Unauthenticated remote attackers can exploit deprecated OpsDirector functionality in Progress MarkLogic Server 12.x before 12.1.0 and 11.x before 11.3.7 to perform server-side request forgery (SSRF), making unauthorized requests to internal services or forging trusted requests that may expose protected information. Exploitation is conditional on the OpsDirector component being present and network-reachable; no public exploit code has been identified at time of analysis. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) indicates high confidentiality impact with no integrity or availability impact.

Privilege abuse in Progress MarkLogic Server 12.x before 12.1.0 and 11.x before 11.3.7 lets a remote attacker who already holds delegated database-administrator privileges run backup or restore operations against forests outside their authorized database scope, resulting in unauthorized read or modification of security-critical data. The flaw is rated CVSS 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) under CWE-269 (Improper Privilege Management), and because exploitation requires the pre-existing delegated DB-admin role it is an authenticated privilege-abuse issue rather than an unauthenticated pre-auth bug. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; no EPSS data or proof-of-concept reference was supplied, so the realistic threat model is a malicious or compromised privileged tenant administrator.

Path traversal in the legacy InfoStudio modules shipped with Progress MarkLogic Server lets a low-privileged authenticated remote attacker reach files outside the intended module directory and, because user-context values are also insufficiently validated, potentially have code run under an unintended identity. Affected deployments are MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 that still have the legacy InfoStudio modules present and reachable. The vendor rates this 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), reflecting a confidentiality-first impact that crosses a security boundary; no public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited, but fixed builds are already available, so this is a priority patching item rather than an emergency.

Server-side request forgery in Linux-based Progress MarkLogic Server 11.x and 12.x allows an authenticated, low-privileged user to coerce the database server into making HTTP requests toward internal endpoints reachable from its network position, which in cloud-hosted deployments can expose instance metadata services and the cloud credentials they hold. Exploitation requires valid low-privilege credentials (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) plus a deployment where an internal metadata or credential service is actually reachable, so on-premises or otherwise isolated installations gain no credential-theft payoff and no unauthenticated path exists. Only releases before 12.1.0 (12.x) and before 11.3.7 (11.x) are affected, and no public exploit code or confirmed active exploitation was identified at time of analysis.

Improper authentication in the CGI handling of Netcore NR268 firmware 1.7.121109 allows remote, unauthenticated attackers to bypass authentication on the device's Boa-based web management interface via the user_ok function, which fails open rather than denying the request. Publicly available exploit code exists (a detailed report is published on GitHub), and the vendor was contacted but did not respond or release a fix. Exposure is the practical risk driver: devices whose HTTP management/CGI interface is reachable from the WAN or an untrusted LAN segment are at high risk, while deployments restricting management to a trusted internal interface are substantially lower risk.

Improper validation of SAML assertions in Progress MarkLogic Server lets an unauthenticated remote attacker cause the server to accept an assertion that should have been rejected, potentially yielding unauthorized access to the MarkLogic deployment and its data. Affected are 12.x releases before 12.1.0 and 11.x releases before 11.3.7, but only instances explicitly configured to use SAML authentication and whose SAML endpoints are network-reachable are exposed to this flaw. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N), no credentials and no user interaction are required; no public exploit code was identified at time of analysis, and the vendor has published fixed versions 12.1.0 and 11.3.7.

Authentication bypass in ZITADEL's Login V2 UI (versions 3.0.0 through 4.19.1) allows unauthenticated attackers to take over user accounts, including administrators with MFA completed, by forging unsigned session cookies and guessing time-ordered session IDs around a victim's sign-in to trigger token rotation. Exploitation requires the target to run the affected Login V2 UI and the attacker to hit a narrow timing window; no public exploit code is identified at time of analysis. While the CVE carries a CVSS 4.0 score of 9.2, the independent assessment rates it with high attack complexity (CVSS 3.1 AV:N/AC:H/PR:N/UI:N), reflecting the timing prerequisite.

Authentication bypass in ZITADEL 4.x before 4.19.2 and 3.x through 3.4.15 lets an authenticated attacker with organization-administrator permission register a SAML identity provider using their own signing key and then obtain authenticated sessions as any user linked to a different SAML provider on the same instance, including users in other organizations. The flaw stems from the SAML identity-provider intent callback verifying the assertion signature against the provider named in the request URL while resolving the user from the login intent without confirming the two match. This is a genuine high-priority vulnerability, though not a 'spray-and-pray' internet-wide threat; exploitation requires the org-admin prerequisite and that victims authenticate via SAML identity providers. No public exploit identified at time of analysis, and a vendor-released patch exists (4.19.2 and later for 4.x; a fix beyond 3.4.15 for 3.x).

Unauthenticated username-change in ZITADEL's hosted Login V1 UI lets a remote attacker rename any active human account - including administrators - by supplying only the victim's login name, locking legitimate users out of the identity provider. The underlying defect is CWE-306 (missing authentication for a critical function): the change-username handler acts on the account bound to the login flow before any authentication factor is verified, so deployments running ZITADEL 3.0.0 through 4.17.x with Login V1 enabled are exposed, while instances on a newer login flow or already upgraded to 4.18.0+ are not. No public exploit identified at time of analysis and no CISA KEV listing applies; the assessed CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L describes a high-integrity, low-availability impact bounded to the Login V1 population, consistent with the VulnCheck-reported CVSS 4.0 score of 8.8.

SurrealDB versions before 3.3.0 fail to validate a caller's authorization level when the SurrealQL USE statement switches the session to a different namespace or database, allowing an authenticated tenant to cross tenant boundaries and read, create, update, or delete rows in other tenants' tables wherever the table's PERMISSIONS clause permits it (for example PERMISSIONS FULL). Exploitation requires a valid account at the namespace, database, or record level (CVSS 4.0 vector PR:L, unauthenticated access is not possible) and only has impact on instances hosting multiple tenants with permissively configured tables. The vendor has released 3.3.0 to correct the missing authorization check; no public exploit code has been identified at time of analysis, and the flaw is not listed in CISA KEV.

Cross-tenant data access in SurrealDB before 3.3.0 allows an authenticated namespace- or database-level SYSTEM user to bypass namespace/database scoping and read, create, modify, or delete rows and read DEFINE PARAM values in other tenants where table PERMISSIONS clauses permit. The CWE-639 authorization bypass is triggered by setting the Surreal-NS/Surreal-DB headers on the /sql endpoint or invoking the RPC 'use' method, as the server fails to validate the caller-selected namespace or database against the level at which the user authenticated. No public exploit identified at time of analysis; impact is limited to multi-tenant deployments and requires valid low-privilege credentials.

Authorization bypass in SurrealDB 3.0.0 through 3.3.0 allows authenticated record users to read records from other namespaces or databases by resolving record IDs via FETCH queries. Attackers can switch to a foreign namespace/database and use a RETURN … FETCH query to read another tenant's data if table PERMISSIONS allow reads. No public exploit identified at time of analysis; exploitation requires a valid authenticated session, multi-tenant deployment, and knowledge of a specific record ID.

Deny-pattern bypass in Network-AI's ClaudeHookBridge PreToolUse hook (versions 5.14.0 through 5.15.1) allows a prompt-injected agent to smuggle dangerous payloads past configured denyPatterns by placing a benign value in the first candidate field the hook inspects (such as file_path or command) while putting the actual malicious content in a secondary field the hook never evaluates, notably the Write tool's content parameter or an MCP script parameter - enabling web shell writes or script execution inside the local agent-execution context. The affected deployment must rely on the PreToolUse hook with denyPatterns as its guardrail, and exploitation additionally requires a successful prompt injection into the agent, which is why risk is bounded to local agent workflows rather than remote reachability; CVSS 4.0 scores 7.5 with attack requirements present (AT:P), and the assessed CVSS 3.1 vector is AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, meaning no prior authentication or user interaction is required per the vector but the attack is local and complex. There is confirmed actively exploited status not present - no CISA KEV listing and no public exploit code - so at time of analysis no public exploit identified at time of analysis; EPSS, SSVC, and KEV signals were absent from the supplied intelligence, so prioritization inputs remain incomplete.

Authenticated role administrators in Admidio 4.3.2 through 4.3.17 and 5.0.0 before 5.0.15 can add users to roles belonging to a different organization on the same instance, escaping their own tenant's authorization boundary and gaining privileged membership that lets them sign in to the target organization and modify its user profiles. The flaw is a missing cross-organization ownership check on the role UUID submitted to members_assignment.php (CWE-639), rated CVSS 4.0 8.5 and assessed independently as CVSS 3.1 8.5 (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N). Exploitation is gated on the attacker already holding role-administrator rights and on the deployment hosting more than one organization, so single-org installations and anonymous or low-privilege users cannot reach the vulnerable path; no public exploit code has been identified at time of analysis and there is no CISA KEV listing. This is a genuine but conditional priority, bounded to insiders or compromised administrator accounts.

Unauthenticated information disclosure in Grav CMS 2.0.22 through 2.1.6 lets attackers read sensitive Clockwork profiler records - including system and plugin configuration, secrets, request metadata, and database queries - when the profiler is active and the site sits behind a same-host HTTP proxy. The flaw is an authentication bypass: the profiler treats any request whose REMOTE_ADDR is a loopback address (e.g. 127.0.0.1) as an authorized local client, so requests forwarded through a co-located proxy inherit that trust. Exploitation is conditional rather than trivial - the profiler is a debug feature and must be enabled, and the attacker must be able to reach the application through the loopback-presenting proxy path; no public exploit code was identified at time of analysis, and this is not a CISA KEV entry. The impact is confidentiality-only (no integrity or availability effect) and is best characterized as a genuine but conditional disclosure flaw rather than a blanket high-severity emergency.

Two-factor authentication bypass in the Grav Login plugin versions 2.7.0 through before 3.9.9 allows an authenticated remote attacker who already possesses a valid password to restore a remember-me cookie issued after the password step and obtain a fully authorized session without completing the second factor, yielding high confidentiality and integrity impact. This is a genuine elevated-priority issue for environments using the plugin with 2FA and remember-me enabled, though not a mass-exploitation emergency; no public exploit identified at time of analysis.

Authentication bypass in Grav Login plugin versions 2.7.0 before 3.9.9 allows attackers who already know a victim's password to disable two-factor authentication (2FA) and take over the account by invoking the update_user task through a published page form without an access rule. The flaw resides in processUserProfile(), which verifies that a session user exists but fails to confirm that a pending front-end 2FA session is fully authorized. Exploitation requires three conditions: the attacker must possess the victim's password, have an in-progress front-end login that has reached the 2FA step, and be able to publish a Grav page form lacking an access rule; no public exploit has been identified at time of analysis.

Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 validate authentication tokens incorrectly, accepting a token the server should reject, so a remote attacker who can reach the instance can obtain unauthorized access under that token's identity. The vendor-published CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), while our independent assessment raises the confidentiality impact to High (C:H/I:H/A:N), reflecting that an improperly accepted token may expose data as well as permit modification; neither vector assesses any availability impact. No public exploit code or confirmed active exploitation was identified at time of analysis (the CVE is not in CISA KEV) and no EPSS score was available in the supplied data, so the realistic limiting factor is deployment exposure: the MarkLogic instance must be network-reachable by the attacker.

MarkLogic Server 11.x before 11.3.7 and 12.x before 12.1.0 can write security-sensitive values - information that enables access to protected resources - into diagnostic logs when the server is running in specific, non-default configurations. Anyone who can already read those logs (filesystem access, a log-aggregation/SIEM pipeline, backup or archive copies, or an account permitted to view logs) can harvest that data and use it to obtain unauthorized access, so the exposure is genuine but gated on two preconditions: a particular logging configuration must be present, and the attacker must already hold low-privileged log read access. No public exploit code or confirmed active exploitation (no CISA KEV listing) was identified at time of analysis, and the independent assessment rates this as a confidentiality-only, local-context issue (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), making it a moderate-priority hardening problem rather than an emergency despite the 8.1 vendor score.

Insufficient isolation in Progress MarkLogic Server 12.x before 12.1.0 and 11.x before 11.3.7 allows code executed through REST Client API and XDBC evaluation paths to reach the surrounding HTTP request, response, and session state, enabling unauthorized actions or compromise of an authenticated user's session. The vendor scores this 9.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), but the scope change and full confidentiality/integrity/availability impact only materialize when an attacker can reach an evaluation interface and a victim with an authenticated session triggers it; our assessment rates the prerequisite as authenticated (PR:L) rather than unauthenticated, so exposure is limited to deployments where these endpoints are reachable and in use. No public exploit code has been identified at time of analysis, and the flaw is not confirmed as actively exploited (no CISA KEV listing) as of this report.

Hex, the package manager used by Elixir and Erlang projects, fails to properly scope its 'release-age cooldown' protection in versions 2.5.0 through 2.5.1, allowing an authenticated package owner to slip a freshly published, malicious release past the cooldown. The attacker must already hold package-owner permission on the target package, retire (or rely on a security advisory for) the release locked in the victim's mix.lock, and then wait for the victim to run mix deps.update - at which point Hex.RemoteConverger.build_cooldown_bypass/3 and unsafe_lock_bypass/1 lift the cooldown for every version of that package and its dependencies, so the new release is selected regardless of age. A secondary scoping defect causes the bypass to be keyed on package name alone, extending it to identically named packages in other repositories; cooldown configured through an organization dependency policy is not affected. This is a conditional supply-chain weakness rather than a broadly dangerous remote flaw, and no public exploit or in-the-wild activity has been identified at time of analysis. Patches are available from the vendor in Hex 2.5.2.

Account takeover of registered Thirty Bees customers is possible through an authentication bypass in PasswordController::resolveCustomer() affecting versions through 1.7.0. Unauthenticated remote attackers who know a victim's email and operate on a store with guest checkout enabled can place a guest order using that email, retrieve the resulting guest account's secure_key, and submit it as a password-reset token to reset the victim's password because the application does not distinguish guest from registered accounts. No public exploit identified at time of analysis, but the vendor has released an upstream fix commit (66410fd2a7ca9d1121a4b9551f59637ae6e4bcf1).

Schema-level and Query/Mutation type-level @authentication directives are silently ignored for top-level @cypher fields in @neo4j/graphql versions up to and including 7.6.3, letting unauthenticated remote callers invoke those fields and run the embedded Cypher statements with the GraphQL service account's privileges, which may permit reading and modifying data. Only @authentication placed directly on the individual @cypher field is enforced, so applications relying on schema- or type-level protection are exposed while those annotating each field individually are not. No public exploit code has been identified at time of analysis, and the vendor has released 7.6.4 as the fix.

Authorization bypass in @neo4j/graphql 7.0.0 through 7.6.3 lets an authenticated user read, create, and delete records that @authorization filter rules were written to deny, because the library translates the 'none' quantifier on relationship and connection filters into Cypher without the required negation so the predicate is evaluated as though it were 'some'. The flaw only manifests in applications whose typedefs actually use the 'none' quantifier inside an @authorization filter on a relationship or connection field (for example creator: { none: { id: { eq: "$jwt.sub" } } }), so applications that never use that construct are not affected; the CVSS vector specifies PR:L, meaning the attacker must hold a valid JWT accepted by the API. No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; a vendor patch and the upstream fix commit are available.

Authenticated users of LogicalDOC Community Edition (versions through 9.3) can bypass folder-level access controls and download the full contents of any restricted folder as a ZIP archive by calling the /zip-export servlet with an arbitrary folderId parameter. Exploitation requires only a valid low-privilege session (CVSS 3.1 PR:L, C:H/I:N/A:N), and because folder IDs are sequential numeric identifiers they can be enumerated, so the practical barrier is low for any user holding an account. The vulnerability is not confirmed as actively exploited (CISA KEV) and no public exploit code was identified at time of analysis, but a vendor fix is available; the impact is limited to confidentiality (document disclosure) with no write or availability effect, making this a moderate-priority information-exposure issue rather than an emergency.

Missing authorization in LogicalDOC Community Edition through 9.3 allows any authenticated low-privilege user to disclose, tamper with, or delete documents they are not permitted to access, by invoking SoapDocumentService operations such as copy, getExtractedText, deleteVersion, reindex, deleteLink, and restore over SOAP or the /services/rest/document REST interface. Because document identifiers are sequential, an attacker with ordinary credentials can simply enumerate IDs and reach other users' content with no administrative rights and no user interaction, yielding high confidentiality and integrity impact with limited availability impact (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L; vendor-published score 8.7). No public exploit code or confirmed active exploitation was identified at time of analysis, and the main barrier to attack is the requirement for a valid account, so exposure is greatest where account creation is open or user segregation is weak.

Authenticated information disclosure in jshERP through 3.6 exposes platform-wide configuration secrets, including SMTP authorization codes (email_auth_code) and activation codes (activation_code), to any logged-in user of any tenant at any privilege level via the getInfoByKey handler of PlatformConfigController. The endpoint applies a denylist that blocks only aliOss and weixin keys, so every other platformKey value is returned unredacted; no admin rights and no user interaction are required, though a valid low-privilege account is a prerequisite (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N; NVD score 7.1). Publicly available exploit code exists - a proof-of-concept script that performs global configuration retrieval and enumeration is hosted on GitHub - but no CISA KEV entry confirms active exploitation, and impact is confined to confidentiality with no integrity or availability effect.

Privilege escalation in jshERP through 3.6 allows any authenticated user, including one holding only minimal privileges, to assign themselves or any other user within the tenant the administrator role through the UserController updateUser (PUT user) handler, which performs no authorization check tying the role change to the caller's own privileges. An attacker sends their own user id together with a tenant administrator roleId (or rebinds another tenant user's role) and obtains full administrative control over business, financial, and user data managed by the platform. Publicly available exploit code exists as a Python proof-of-concept, and with a CVSS 4.0 base score of 8.7 (independently scored 8.7 under CVSS 3.1) the only meaningful precondition is possession of a valid low-privilege jshERP account; no user interaction or non-default configuration is required.

Information disclosure in MoguBlog through 6.2 lets any holder of an ordinary front-end reader session token retrieve unfiltered SystemConfig data - including Qiniu and MinIO secret keys and SMTP mailbox passwords - from the getSystemConfig endpoint over the network. The CVSS 4.0 base score is 7.1 (assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N with high confidentiality impact and no integrity or availability impact), and the prerequisite is only a low-privileged authenticated reader account, which many public blogs allow users to self-register. Exploitation status: publicly available exploit code exists (a PoC script targeting the OAuth getSystemConfig path is published), but there is no confirmed active exploitation (no CISA KEV listing), and real-world impact is bounded by whether the deployment has actually configured Qiniu/MinIO storage or SMTP mail, since those are the credentials exposed.

Insecure direct object reference in lamp-cloud through 5.10.1 lets any authenticated user, regardless of privilege level, list and retrieve file attachments that belong to other business objects or tenants by supplying an arbitrary bizId to the listFileByBizId endpoint exposed by AppendixController. The response leaks file names, storage paths, MD5 hashes and stored URLs, and because the default LOCAL storage mode serves those attachments without login under /anyTenant/file, the referenced file contents themselves can be downloaded anonymously once the metadata has been harvested. Publicly available exploit code exists, but the impact is confined to confidentiality (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), making this a genuine but moderate-priority access-control issue rather than a critical remote-code-execution threat.

Authenticated users of dromara lamp-cloud through 5.10.1 can obtain storage access URLs for files owned by other users by sending arbitrary file ids to the findUrlById handler of FileAnyoneController, which performs no ownership check (CWE-639) and exposes uploaded attachments to unauthorized reading. Exploitation requires only a valid low-privilege account and knowledge or enumeration of victim file ids; publicly available exploit code exists, but the issue is not in CISA KEV and impact is confidentiality-only per the independent assessment (CVSS 4.0 base 7.1; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). This is a genuine but bounded access-control weakness rather than a top-tier emergency.

Authorization bypass in LavaLite CMS through 10.1.2 lets an authenticated low-privileged user modify other users' accounts - including administrator accounts - by sending a PATCH request to the user update route carrying a target user identifier, altering the victim's name, email, password, status, or mobile number. The CVSS:4.0 vector (AV:N/AC:L/PR:L/UI:N/VI:H) and the independent CVSS:3.1 assessment (PR:L, I:H, S:U) both confirm that a valid low-privilege login is required, that no victim interaction or non-default configuration is needed, and that the impact is high-integrity write access with no direct confidentiality or availability loss; the practical effect is a route to full administrative account takeover. No public exploit code was identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV), so the principal exposure limiter remains the need for an existing low-trust account, which narrows realistic risk to deployments that allow self-registration or where an attacker already holds low-level credentials.

An incorrect authorization flaw in the WinBox authentication flow of MikroTik RouterOS lets a remote authenticated attacker who holds valid credentials for a low-privilege, WinBox-permitted account take over the authorization policy of a different, higher-privileged account such as admin. The EC-SRP stage-one challenge and proof are validated against the attacker's own account, but the separately supplied stage-two username determines which privilege policy gets installed, so the attacker ends up with a full administrative session without ever knowing the admin password, and can then use it to elevate their own account. Coverage across ENISA and CERT.LV reporting with a CVSS 4.0 score of 8.7 indicates a high-severity, network-reachable issue; no public exploit code has been identified at time of analysis. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, meaning exploitation requires one valid low-privilege WinBox-enabled credential and network reachability to the WinBox service.

Authentication bypass in ((OTRS)) Community Edition 6.x and earlier lets an unauthenticated remote attacker impersonate any existing agent or customer account when HTTP Basic Authentication is the configured authentication backend. Because the CGI/mod_perl deployment maps an attacker-supplied 'Remote-User' request header into the HTTP_REMOTE_USER environment variable, OTRS treats that header value as an already-authenticated username and skips password verification, after which the Generic Interface can be accessed with the impersonated account's privileges. Exploitation is not unconditional: it requires Basic Auth to be the active backend, a CGI/mod_perl (not Mojolicious/Hypnotoad) deployment, and knowledge of a valid target username, which is why an independent assessment rates the attack complexity as High (AC:H) rather than the vendor's AC:L, and no public exploit code was identified at time of analysis. OTRS 7 and later are unaffected by this vector.

pH7Builder (pH7 Social Dating CMS) versions before 18.6.0 leak sensitive member records - email addresses, IP addresses, phone numbers, and bank account fields - to unauthenticated remote attackers who bypass the API's access checks. The bypass works because Tool.class.php ships a hard-coded API key (private_api_key=dev772277) and the authorization logic trusts the client-supplied Host header, so an attacker sending 'Host: localhost' along with that static key and the shipped default allowed URL is treated as authorized. No public exploit code has been identified at time of analysis and there is no KEV entry, but the independent assessment scores the issue CVSS v3.1 7.5 (AV:N/AC:L/PR:N/UI:N, C:H/I:N/A:N), a high-priority confidentiality-only exposure, with the vendor shipping 18.6.0 as the fix.

Authenticated users of any privilege level on JeecgBoot through 3.9.5 can rewrite DingTalk, WeCom, or Feishu third-party integration settings - client id, client secret, agent id and corp id - through the unprotected editThirdAppConfig handler, redirecting directory synchronisation and messaging to attacker-controlled applications or breaking the integrations outright. The defect is a missing authorization check (CWE-862) in ThirdAppController.java with an assessed integrity impact (CVSS 3.1 base 7.1, PR:L, I:H), and publicly available exploit code exists, though no confirmed active exploitation (CISA KEV) is reported. Real-world impact is context-dependent: instances with no configured third-party IM/directory integration expose little to steal or disrupt through this endpoint.

Unauthenticated remote attackers can bypass authentication in AmoyLab Unla through 0.10.0 by exploiting an OAuth2 authorization server that never authenticates a resource owner, allowing them to register a client, request an authorization code, and exchange it for a valid access token. This grants access to OAuth2-protected MCP prefixes, proxied upstream APIs, and injected credentials, with high confidentiality impact and low integrity impact. No public exploit identified at time of analysis, and no vendor-released patch is available; the vulnerability is remotely exploitable without authentication or user interaction, making it a high-priority issue for exposed instances.

Unauthenticated information disclosure in Katanemo Plano through 0.4.37 allows any network attacker who can reach TCP port 9901 to read plaintext LLM provider API keys by issuing a single GET request to the Envoy admin interface's /config_dump endpoint. The Envoy admin listener is bound to all host interfaces (0.0.0.0) in the shipped config/envoy.template.yaml, so stock deployments are exposed by default; the only real barriers are network reachability to port 9901 and the presence of at least one configured provider key, and the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, C:H) reflects a low-effort, high-reward credential theft with no authentication or user interaction required. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, although the flaw has been publicly documented by VulnCheck.

Hard-coded JWT signing key in BotSharp through 5.2.0 allows unauthenticated remote attackers to forge bearer tokens and impersonate any user, including administrators, on Authorize-protected API routes. Exploitation requires the deployment to retain the default key and default 'botsharp' issuer/audience; rotating these values mitigates the issue. No public exploit code has been identified at the time of analysis, but the high impact and low complexity make this a genuine high-priority risk as confirmed by independent assessment.

Authenticated low-privileged users on UnicomAI Wanwu deployments running versions before 0.6.3 can permanently delete other tenants' agent and RAG applications by sending a DELETE request to /v1/appspace/app with a guessed appId, because the pre-patch handler performs no ownership check on the supplied identifier. The vulnerability is an IDOR (CWE-639) and is exacerbated by sequential, predictable assistant IDs, which makes enumeration of victims' appIds practical; deletion also cascades to associated workflows, conversations, and linked data, giving high integrity and availability impact (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, vendor score 7.2). Exploitation requires a valid low-privileged account on a multi-tenant instance with other tenants' applications present, and no public exploit code has been identified at time of analysis, though a detailed technical writeup and patch commit are publicly available.

Signature verification bypass in hyper-mcp through 0.8.3 (src/wasm/oci.rs, load_wasm) lets an unauthenticated remote attacker who controls or tampers with OCI registry responses for a resolved tag load and execute unsigned WebAssembly plugins that were never covered by the Cosign signature check. The flaw is a time-of-check/time-of-use race (CWE-367): Cosign verifies a separately resolved tag while the loader consumes a different manifest, so a malicious registry can serve a signed manifest to the verifier and an unsigned malicious one to the plugin loader, with the payload then running under whatever host capabilities the operator granted. Exploitation is constrained - it requires signature-verified OCI plugin loading to be enabled, an active position on the registry channel, and winning the resolution race - and no public exploit code or confirmed active exploitation was identified at time of analysis.

Unauthenticated appointment takeover in Easy!Appointments 1.6.0 and earlier allows any remote attacker to rewrite, rebind, reschedule, or cancel arbitrary existing bookings by calling the public Booking::register() endpoint with a sequential appointment id and a self-asserted manage_mode flag while omitting the appointment management hash. Successful abuse also yields the victim's management hash, its update endpoint is reachable at PR:N/UI:N, and the flaw carries an assessed impact of high integrity loss, making it a genuine priority rather than a high-CVSS paper tiger; no public exploit identified at time of analysis, although a public technical write-up of the flaw exists, and no EPSS score was supplied in the available data.

Blind prompt injection into a user's OpenClaw agent session is possible through the Pinclaw channel plugin version 0.3.0 and earlier, because the HTTP router skips the authToken check on POST /pinclaw/send. The service binds all interfaces on port 18790 by default, but per the assessed CVSS vector exploitation requires adjacent-network access (same LAN or Wi-Fi) rather than arbitrary internet reachability, so real-world risk is moderate rather than urgent. Successful abuse lets an unauthenticated attacker plant instructions into the victim's agent session, affecting integrity only; no public exploit code has been identified at time of analysis.

Unauthenticated remote attackers can achieve full administrative control of self-hosted Agnai instances (versions through 1.0.555) deployed with the default self-host.docker-compose.yml, which contains a hard-coded admin password and a public JWT secret. Attackers can log in as admin or forge a JWT with admin privileges to impersonate users, reset passwords, and modify server configuration. This critical vulnerability (CVSS 9.3) requires no user interaction and no prior authentication, but exploitation is limited to instances that have not overridden the default credentials and are network-reachable. No public exploit code has been identified at the time of analysis, though the hard-coded secrets are publicly visible in the repository.

Incorrect authorization in Vearch 3.5.2 through 3.5.9 lets any authenticated non-root user who holds a role with ReadOnly or None resource privileges perform write operations that role should forbid. Because Role.HasPermissionForResources ignores the stored privilege level, such a user can upsert and delete documents and can call PUT /roles to grant their own role WriteRead privileges, escalating toward cluster-administrator access. Exploitation requires valid low-privilege credentials (PR:L) and is limited to the 3.5.2-3.5.9 range, so exposure is greatest in multi-tenant or shared deployments where untrusted users hold accounts; no public exploit code or confirmed active exploitation was identified at time of analysis.

Unauthenticated information disclosure in OpenAgents Workspace (through launcher-v1.0.17) enables remote attackers to list all workspaces and retrieve sensitive data-including the unmasked browserfabric_api_key, workspace IDs, slugs, creator emails, and member lists-via a single GET /v1/workspaces request. The endpoint lacks authentication (CWE-306), so exploitation requires only network reachability to the backend API. No public exploit code or CISA KEV listing is reported; however, the exposure of API credentials creates a high confidentiality risk, consistent with the CVSS 4.0 base score of 8.7 and independent assessment.

Unauthenticated attackers can download private Corteza compose attachments by rewriting the 'kind' path segment of the original or preview serving route to 'page', 'icon', or 'namespace', which makes the platform's isAccessible() check treat the private file as a public-kind attachment and skip the token/signature verification that would normally gate it. Deployments at or below Corteza 2024.9.10 that expose the compose attachment endpoints are affected, and an attacker only needs to know or guess a valid private record or module attachment ID - that requirement is reflected as Attack Requirements: Present (AT:P) in the vendor's CVSS 4.0 score of 8.2 (High), while the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Per available intelligence there is no CISA KEV entry and no public exploit identified at time of analysis, though a public technical write-up of the attachment kind-confusion technique is referenced; EPSS data was not supplied. The impact is confidentiality-only - high-volume unauthorized reads of files across namespace and record permission boundaries - with no integrity or availability effect reported.

Unauthenticated attackers can obtain a non-expiring API token carrying a victim's full Rill permissions by abusing open dynamic client registration in the admin OAuth server of Rill Data's Rill 0.77.0 through 0.90.5 (CWE-862, missing authorization). The attacker self-registers an OAuth client with the long_lived_access_token scope and must then convince a logged-in Rill user - typically through a phishing authorization link - to approve it, because exploitation requires user interaction and cannot be executed silently against the server alone; the resulting access is bounded by the lured user's privilege level, so a high-privilege victim yields correspondingly broad, non-expiring access. Rill is not listed in CISA KEV and no public exploit has been identified at time of analysis, although a public technical writeup of the technique is linked from the advisory; the CVSS 4.0 base score is 8.6, and the independent assessment rates this a credible, above-average priority issue rather than an inflated high-CVSS score.

NornicDB through 1.4.1 fails to enforce per-database read restrictions on its vector-search endpoints, so an authenticated viewer-role user who is allowlisted for a database but explicitly denied read permission can still submit search queries or node IDs to /nornicdb/search and /nornicdb/similar and retrieve node IDs, labels and full property maps. The flaw is rated CVSS 4.0 7.1 (HIGH) and is confidentiality-only (CWE-862 missing authorization), requiring valid credentials (PR:L) plus a deployment that actually uses per-database allowlisting with read denial - instances without granular policies have nothing to bypass. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV).

Unauthenticated attackers can reset, overwrite, or replace the post password of every published post on any WordPress site running the WP Posts Password Batch Manager plugin through version 1.1, because the plugin's bulk post-password handler is registered on an always-loaded admin handler and performs neither a capability check nor a nonce check. Successful exploitation with a single crafted request gives the attacker either disclosure of all password-protected post content (by clearing or resetting known/blank passwords) or a denial-of-service/lockout condition by setting every published post behind an attacker-chosen password, matching the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L (high integrity impact, low confidentiality and availability impact). Publicly available exploit code exists (the WPScan entry is tagged as an exploit reference), and no CISA KEV entry is associated with this CVE, so this is not confirmed as actively exploited; the practical risk is concentrated in the narrow set of sites that actually have this low-prevalence plugin installed and active, with published, password-protected content.

The Disable Users WordPress plugin (versions through 1.0.5) fails to apply its account-disabling control consistently across all authentication paths, so an attacker who holds the credentials of an account an administrator has disabled can still log in and operate with that account's original privileges. Exploitation requires pre-existing valid credentials for a previously disabled account (CVSS PR:L, base score 8.8), and the regained access is bounded by the role that account held - but where the disabled user was an administrator, the result is full site compromise (C:H/I:H/A:H). Publicly available exploit code exists per the WPScan disclosure; there is no indication of confirmed active exploitation (no CISA KEV entry in the provided data).

Unauthenticated remote attackers can delete arbitrary WordPress options in sites running the Insurify WordPress plugin through version 1.0, due to missing authorization and nonce checks on an AJAX action, potentially taking the site offline and stripping every user of their role. Publicly available exploit code exists, and the vulnerability is remotely exploitable with no authentication required (CVSS 9.1). Any site with the vulnerable plugin active is at risk.

Unauthenticated remote attackers can rewrite arbitrary WordPress site settings through an AJAX action exposed by the Quick Quotes plugin through version 1.0.0, which performs no capability or nonce validation on the request. Successful abuse allows an attacker to change site-wide options - including those that can render the site unreachable - with no authentication, no user interaction, and no non-default configuration required, yielding an assessed CVSS of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H). Publicly available exploit code exists per the WPScan disclosure, though the plugin's obscure deployment footprint limits the broader blast radius; there is no indication of confirmed active exploitation (not in CISA KEV) and no vendor-released patch was identified at time of analysis.

Unauthenticated remote attackers can overwrite arbitrary WordPress options on any site running the Insurify plugin through version 1.0, because one of the plugin's AJAX actions performs neither a capability (authorization) check nor a nonce/CSRF check - a CVSS 3.1 score of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H) reflects high integrity and availability impact with no privileges or user interaction required. Exploitation can rewrite site-critical options, take the site offline, and deactivate the plugin itself, and publicly available exploit code exists (per the WPScan report and its exploit-tagged reference); there is no indication of confirmed active exploitation (not listed in CISA KEV). The practical constraint is the plugin's limited deployment footprint, not any technical barrier.

Authentication bypass in the Freeton WP WordPress plugin through version 1.0.0 lets unauthenticated attackers log in as any existing user, including administrators, using only that user's email address, because the plugin does not correctly validate the activation code used during authentication. The flaw is rated 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-287) and requires no credentials and no user interaction; publicly available exploit code exists (referenced from the WPScan entry), and no CISA KEV listing indicates confirmed active exploitation. Exposure is limited to WordPress sites where the plugin is installed and active - an important qualifier given the plugin's small footprint - but for those sites the practical barrier is only knowledge of a valid account email, which is commonly obtainable through WordPress author enumeration.

Authentication bypass in the Mindstien Quick Login WordPress plugin through version 1.0 allows unauthenticated remote attackers to obtain an administrator session on any affected site where the plugin is active and configured with an administrator account. The flaw (CWE-287) stems from the plugin failing to validate a request-supplied value against the visitor's own session before authenticating them, yielding a CVSS 3.1 base score of 9.8. Publicly available exploit code exists, and while the vulnerability is not confirmed as actively exploited (CISA KEV), the low attack complexity and lack of required authentication make immediate remediation critical.

Unauthenticated option manipulation in the click5 CRM add-on to Contact Form 7 (versions through 1.0.4) lets remote attackers rewrite arbitrary WordPress options without authorization, a nonce, or any user interaction, which is sufficient to enable user registration and create a new administrator account for full site takeover. The flaw carries a 9.8 CVSS score (AV:N/AC:L/PR:N/UI:N), and publicly available exploit code exists, making this a realistic and high-priority target for mass scanning against any WordPress site that has this specific add-on installed and active; Contact Form 7 alone, or WordPress without the add-on, is not affected. No CISA KEV entry was provided, so active exploitation is not independently confirmed, but the combination of unauthenticated reachability, trivial preconditions, and published exploit code warrants urgent triage and removal or blocking of the vulnerable endpoint.

Unauthenticated option manipulation in the click5 CRM add-on to Gravity Forms (versions up to and including 1.0.3) lets any remote attacker rewrite arbitrary WordPress blog options and escalate to complete site takeover by enabling open registration with an administrator default role, thereby creating a new admin account. The flaw is a missing authorization/CSRF class issue exposed through a REST endpoint that neither checks the caller's capabilities nor verifies that the targeted option belongs to the add-on, so no credentials, nonce token, or user interaction are required against a default configuration. Publicly available exploit code exists, and the only real prerequisite is that the affected add-on be installed and active on a reachable WordPress site; no CISA KEV entry was present in the supplied intelligence, so active exploitation is not confirmed.

Unauthenticated attackers can take over any WordPress site running the click5 CRM add-on for WPForms (versions through 1.0.3) by abusing a REST endpoint that updates blog options without authorization, CSRF validation, or any check that the targeted option belongs to the add-on. Because the endpoint accepts arbitrary option names, an attacker can set registration-related options and a default administrator role to create a new admin account, or otherwise alter site configuration, leading to full site compromise. The flaw carries a CVSS v3.1 base score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), publicly available exploit code exists, and exploitation requires only that this niche add-on be installed and active.

Unauthenticated option overwrite in the click5 CRM add-on to Ninja Forms allows any remote attacker to write arbitrary WordPress blog options on sites running the add-on at version 1.0.1 or earlier, a primitive that can be chained into creating a rogue administrator account and complete site takeover. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N with high confidentiality, integrity and availability impact (9.8), so the CVSS vector confirms no authentication and no user interaction are required against default configurations that simply have the add-on active. Publicly available exploit code exists, tracked by WPScan and mirrored in ENISA EUVD as EUVD-2026-96753, while there is no confirmed actively exploited (CISA KEV) status at time of analysis; exposure is bounded by the add-on's niche deployment rather than by any authentication or non-default configuration requirement.

Unauthenticated remote attackers can seize control of the payment configuration on WordPress stores running the Fundiin cho WooCommerce plugin through 3.4.0, because several of its REST API routes enforce authorization only through a credential that is hardcoded identically in every installation. Exploiting this yields disclosure of the store's payment gateway credentials and customer order data, allows the gateway configuration to be rewritten so that payments are credited to an attacker-controlled destination, and permits unpaid orders to be marked as paid; the same missing authorization additionally allows script to be stored and rendered unescaped on the classic WooCommerce checkout, producing unauthenticated stored XSS. CVSS 3.1 scores this 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) and publicly available exploit code exists per the WPScan report, while no CISA KEV entry was present in the supplied intelligence.

Unauthenticated attackers can permanently delete arbitrary posts, pages, and media attachments on WordPress sites running WeddingCity Lite version 1.0.4 or earlier due to missing authorization checks in the plugin's deletion handler. The flaw, tracked as CWE-862, is remotely exploitable without authentication (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) and affects default installations with the plugin active. Publicly available exploit code exists, though no confirmed active exploitation (CISA KEV) has been reported; the risk is high for affected sites due to the trivial attack requirements, but exposure is limited by the plugin's niche install base.

Authenticated vendor (store_owner) accounts in the MultiVendorX WooCommerce plugin through 5.0.19 can silently overwrite marketplace-wide commission, payout, and onboarding settings by sending POST requests to /wp-json/multivendorx/v1/settings, because that REST route is authorized only against the low-privilege edit_stores capability instead of an administrator-level capability (CWE-863). The practical outcome is high integrity impact on marketplace configuration - a vendor can rewrite commission rates and payout rules in its own favor - with no user interaction and no administrator action required, while availability impact remains limited. Exploitation requires the attacker to already hold a vendor account with edit_stores on the target store, so exposure is greatest where vendor registration is open or self-service; no public exploit code has been identified at time of analysis and there is no CISA KEV entry, making this a moderate-priority broken-access-control (privilege boundary) issue rather than a pre-authentication compromise.

Missing authorization in Wukong HRM (all versions through commit 186115e) lets any authenticated employee, including the lowest-privileged role, read company-wide payslips, salary records, bank card details and personal data, edit bank cards, and delete employees, departments and contracts. The defect is structural: the HR administrator role is unconditionally assigned to every caller and data-scope checks return the entire employee set instead of the caller's permitted scope, so both horizontal and vertical privilege boundaries collapse for any valid session. Publicly available exploit code exists - two PoC scripts targeting salary archive history and payroll card/Social Security data - so anyone with valid low-privilege employee credentials and network reach to the HRM web application can exploit this reliably; no KEV listing or confirmed active exploitation is present in the available data.

Unauthenticated attackers can reach every Wukong_HRM API endpoint and operate with HR administrator privileges, because the platform's ParamAspect authorization component treats an absent AUTH-TOKEN header as an implicit pass instead of a denial. Exploitation requires nothing more than network reachability to the HRM API on a build at or before commit 186115e - no credentials, token, configuration change, or user interaction - and it exposes payslips, salary history, and employee personal data, permits attachment downloads, and allows modification or deletion of company-wide HR records. Publicly available exploit code exists (multiple proof-of-concept scripts published alongside the VulnCheck advisory), the CVSS 4.0 base score is 9.3, and no confirmed active exploitation (CISA KEV) has been reported; the risk is nevertheless genuine rather than CVSS-inflated, since the bypass is triggered by simply omitting a request header.

Missing authorization in 1Panel-dev CordysCRM before 1.9.2 lets any authenticated low-privileged user read organization invoicing entities by sending POST /field/source/business-title, an endpoint that performs no permission check and therefore ignores the CONTRACT_BUSINESS_TITLE_READ privilege. Successful exploitation exposes tax identification numbers, bank account numbers, opening banks, registration addresses, and phone numbers of customer organizations, giving an attacker a ready-made dataset for invoice fraud, business email compromise, and social engineering. Publicly available exploit code exists (a Python PoC published on GitHub), and the issue is confirmed fixed in 1.9.2; per the CVSS:4.0 vector (PR:L, no UI, network-reachable), the practical barrier is simply holding valid low-privilege credentials, so an insider or a compromised standard account is enough to pull the data.

Missing authorization in 1Panel-dev CordysCRM 1.9.0 up to (but not including) 1.9.2 lets an authenticated user who has been explicitly denied module permission page through organization-wide CRM records - leads, contacts, quotations, contracts, payment plans, payment records, orders and invoices - that belong to other users. The flaw lies in eight ModuleFieldController /field/source data-source endpoints that omit the data-permission scope check, so a low-privilege account (CVSS PR:L, unauthenticated attackers cannot exploit it directly) can enumerate and read data it should never see; impact is confidentiality-only with no integrity or availability effect. Publicly available exploit code exists (a proof-of-concept script targeting the field/source endpoint family), and the vendor has released a fix in 1.9.2 via commit a31fa16f, which injects a dataPermission.invisible guard into the affected MyBatis mappers and the controller.

Authenticated low-privileged users of JeecgBoot through 3.9.5 can retrieve any other user's stored password ciphertext through the GET /sys/api/getUserByName endpoint, which lacks authorization checks. Because the platform exposes its hard-coded AES-CBC encryption key via /sys/getEncryptedString, an attacker holding only a basic account can decrypt the returned password values locally and then subject administrator credentials to offline guessing. Publicly available exploit code exists, and exploitation requires a valid low-privileged account (PR:L) with network reachability, making this a genuine but moderate-priority credential-disclosure issue rather than an unauthenticated critical flaw; no CISA KEV entry indicates confirmed active exploitation at time of analysis.

Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user enumerate record IDs through the unguarded /airag/app/queryById endpoint and then read MCP (Model Context Protocol) server configurations - including endpoint URLs, HTTP headers and outbound authentication tokens - because the permission check in AiragMcpController.queryById is commented out. Exploitation requires a valid JeecgBoot session at any privilege level (CVSS v4.0 PR:L, assessed CVSS 3.1 PR:L) and a deployment that actually uses the AiRAG/MCP feature with stored MCP records; a stock install without configured MCP servers exposes nothing sensitive. Publicly available exploit code exists, though the issue is a moderate-priority information-disclosure flaw (high confidentiality impact, no integrity or availability impact) rather than a remote-takeover bug, and no CISA KEV entry indicates confirmed active exploitation.

Tenant ownership takeover in JeecgBoot through 3.9.5 lets any authenticated user - regardless of privilege level - reassign a tenant's owner by sending userId and tenantId to POST /sys/tenant/changeOwenUserTenant, stripping the legitimate owner and potentially installing the attacker or an accomplice as the new owner. The root cause is a missing authorization check (CWE-862) on the multi-tenant owner-change handler, rated CVSS 7.1 (CVSS:4.0 PR:L, UI:N, integrity-only impact), and publicly available exploit code exists. Exploitation is not drive-by: it requires a valid account on the target and a deployment where the multi-tenant feature is enabled, making this an access-control-bounded integrity risk rather than anonymous remote compromise.

Privilege escalation in JeecgBoot through 3.9.5 lets any authenticated user approve their own pending tenant administrator application and obtain tenant-admin ('tenant pack') permissions across any tenant. The SysTenantController passApply handler performs no authorization check, so a low-privilege account can file an application via doApplyTenantPackUser and then approve it with a PUT to /sys/tenant/passApply, reaching high confidentiality and integrity impact without user interaction or elevated privileges (assessed CVSS 3.1 8.1, PR:L). Publicly available exploit code exists - a Python proof-of-concept for tenant ownership and pack approval is published on GitHub and referenced by VulnCheck - but no CISA KEV entry has been reported, so confirmed active exploitation cannot be asserted.

Database credential disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to retrieve JDBC connection URLs, database usernames, and decrypted cleartext database passwords from the GET /sys/api/getDynamicDbSourceByCode endpoint of SystemApiController. The handler carries no Shiro permission or role annotations, so a basic application account is sufficient; the only practical hurdles are obtaining any valid session and knowing or enumerating a valid dbSourceCode value, and exposure requires that dynamic datasources be configured on the instance. Publicly available exploit code exists, and the impact is confidentiality-only (CVSS 3.1 6.5 / CVSS 4.0 7.1, PR:L), with no evidence of confirmed active exploitation at time of analysis.

Missing authorization in the saveDeptRolePermission endpoint of JeecgBoot's SysDepartPermissionController lets any authenticated user - regardless of privilege level - rewrite department role permissions, granting themselves arbitrary menu and button permissions or stripping permissions from other accounts. The flaw affects JeecgBoot through 3.9.5 and requires only a valid low-privilege session (PR:L in the CVSS vector), with no user interaction and no special configuration; publicly available exploit code exists, though there is no confirmation of active exploitation in the wild. The independent assessment rates this a genuine, actionable priority: the sole realistic barrier for an attacker is obtaining one low-privilege credential, so internet-exposed instances that permit self-registration are at direct risk.

JeecgBoot through 3.9.5 ships a system log controller whose batch-delete handler performs no authorization check, so any authenticated user - including the lowest-privileged account - can send a DELETE request with the ids parameter set to the special value 'allclear' and wipe the entire sys_log audit table for every user. The result is silent, organization-wide destruction of audit trail evidence rather than data theft, code execution, or privilege escalation, which keeps the real-world impact bounded. Publicly available exploit code exists (a Python PoC script referenced by VulnCheck), and CISA KEV does not list this CVE as confirmed actively exploited (CISA KEV); the vulnerability is confirmed exploited only in the reported PoC sense, not in observed campaigns. CVSS scores of 7.1 (vendor v4.0 and our assessed v3.1) reflect high integrity impact on the log table with low availability impact and no confidentiality impact.

Unauthenticated remote attackers can delete arbitrary plugin-managed content on any WordPress site running the Forminator form-builder plugin at or below version 1.57.3, because the content-deletion action lacks an authorization check (CWE-862 Missing Authorization). The flaw is trivially reachable: our assessment scores it CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (published base 7.5), meaning no credentials, no privileges and no user interaction are required - only that the plugin is installed, active and its endpoint is network-reachable. Impact is destructive only (forms/submissions and associated content can be wiped) with no confidentiality disclosure or code execution, and no public exploit code was identified at time of analysis; there is no CISA KEV listing and no EPSS data was supplied. Sites that have upgraded past 1.57.3 or that do not run Forminator are unaffected.

Unauthenticated broken access control in the WordPress plugin Barcode Scanner with Inventory & Order Manager (versions 1.13.1 and earlier) lets any remote attacker reach plugin endpoints that handle product, inventory, and order functions without holding any WordPress capability or account (CWE-862, CVSS 3.1 7.3). The flaw is network-reachable with low complexity, no authentication (PR:N) and no user interaction (UI:N), so the only practical precondition is that the plugin is installed and active at a vulnerable version; per the assessed vector, the consequence of each exposed action is limited to Low confidentiality, integrity, and availability effects with scope unchanged, meaning the 7.3 reflects broad reachability rather than severe per-request impact. There is no CISA KEV entry and no public exploit identified at time of analysis, and the affected population is bounded to WordPress sites running this specific plugin. Tracking reference: Patchstack advisory for the plugin's 1.13.1 broken access control vulnerability.

Subscriber-level accounts on WordPress sites running the uListing plugin version 2.2.0 or earlier can invoke a plugin settings-change routine that performs no authorization or capability check, letting the lowest-privileged registered user modify configuration values that should be reserved for administrators (CWE-862, missing authorization). The attack is network-reachable, requires no user interaction and no elevated privilege beyond a valid subscriber session, which is trivial to obtain where open self-registration is enabled - though the CVSS vector (PR:L) confirms an account is a genuine prerequisite. Impact is primarily integrity loss in plugin configuration with some confidentiality and availability exposure (CVSS 3.1 base 7.6 as published; our independent assessment is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L), and the overall picture is a moderate-priority hardening issue rather than an emergency; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.