| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The TillKit WordPress plugin before 1.0.5 does not require the hard-coded, publicly known PIN of the privileged POS account it creates on activation to be changed before use, and it authenticates its public POS login endpoint on that PIN alone with no identity or capability check, allowing unauthenticated attackers to obtain a privileged POS session and thereby read customer and site-user personal data and modify store data. |
| The JSON API Auth plugin for WordPress is vulnerable to Authentication Bypass via Cached Session Cookie Disclosure in all versions up to, and including, 3.1.2. The vulnerability exists because the required PI-Media/json-api parent plugin caches controller dispatch results in transients keyed solely by URI and query string, ignoring HTTP method and POST body; this causes the `generate_auth_cookie()` endpoint — which embeds a live WordPress `logged_in` cookie produced by `wp_generate_auth_cookie()` directly in its JSON response body — to serve that cached authenticated response to any subsequent unauthenticated GET request to the same URI. This makes it possible for unauthenticated attackers to retrieve a valid Administrator `logged_in` session cookie from the cached response and use it to fully authenticate as the site Administrator, including via the same plugin's `get_currentuserinfo` endpoint and any cookie-authenticated controller action. Exploitation requires the PI-Media/json-api parent plugin to be installed and active with the Auth controller enabled, and a legitimate Administrator must have POSTed to `/api/auth/generate_auth_cookie/` within the preceding 24-hour cache TTL; the nominal HTTPS enforcement gate present in `Auth.php` is trivially bypassed by supplying `insecure=cool` as a request parameter. |
| The Burst Statistics – Simple WordPress Analytics (Google Analytics Alternative) plugin for WordPress is vulnerable to Improper Authentication leading to Account Persistence in all versions up to, and including, 3.7.1. This is due to the `maybe_load_shared_dashboard()` handler issuing a genuine WordPress session cookie for the `burst_statistics_viewer` account to any visitor presenting a valid share token via `wp_set_auth_cookie()`, while the plugin only blocks Application Passwords for the resulting `burst_viewer` role and does not restrict the core `/wp-json/wp/v2/users/me` password update endpoint or filter the `edit_user` capability for that account — leaving WordPress core's built-in rule that any authenticated user may update their own account fully in effect. This makes it possible for unauthenticated attackers to set an attacker-chosen password on the `burst_statistics_viewer` WordPress account, constituting a permanent takeover of that limited-privilege (`view_burst_statistics`) account that persists through share-token revocation, share-token expiration, and execution of the plugin's daily `cleanup_viewer_sessions()` routine. Exploitation requires that the attacker have obtained a valid `burst_share_token`, such as one that has been shared publicly or distributed to an untrusted party. |
| The MetForm WordPress plugin before 4.3.1 does not properly restrict access to form submission data, allowing unauthenticated attackers to view submitter information through the REST API. |
| The WP Ultimate CSV Importer WordPress plugin before 9.2 does not use a site-specific secret when deriving the storage location of the import logs it writes under the uploads directory, nor does it block direct access to them, allowing unauthenticated attackers to retrieve the personal data of users imported from a CSV file. |
| The Divi Membership plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 2.3.0. The `process_paypal_callback` function, hooked to the `init` action, accepts a base64-encoded `paypal_param` GET parameter with no IPN validation, no cryptographic signature check, no ownership verification, and no nonce, allowing it to trust an entirely attacker-controlled user ID value that is passed directly to `wp_set_current_user()` and `wp_set_auth_cookie()`. This makes it possible for unauthenticated attackers to log in as any existing WordPress user — including administrators — by supplying an arbitrary user ID in the `paypal_param` GET parameter, resulting in full site takeover. The vulnerability is further compounded by the fact that the PayPal gateway class is instantiated unconditionally regardless of whether PayPal is enabled or configured, ensuring the vulnerable hook is always registered on every front-end request. |
| The DevKit Pro plugin for WordPress is vulnerable to Authentication Bypass Leading to Administrator Account Takeover in all versions up to, and including, 2.3.0 This is due to the `revert_switch` handler trusting the attacker-controlled `original_user_id` cookie as the privileged identity: `verify_nonce_and_capability()` incorrectly checks the `manage_options` capability on the user identified by the cookie rather than on the actual requester via `current_user_can()`, while the switch-back form and a valid session-bound nonce are emitted publicly via `wp_footer` to any visitor — including unauthenticated users — whenever that cookie is present. This makes it possible for unauthenticated attackers to set the `original_user_id` cookie to any administrator's user ID, collect the rendered nonce, and POST it back to the `revert_switch` handler, causing `wp_set_auth_cookie()` to be called with the administrator's ID and granting the attacker a full administrator-level authenticated session and complete site takeover. |
| MISP contains an authorization flaw in its correlation handling during attribute searches. When a user performs an attribute search that triggers correlation lookups, the system authorized access to correlated attributes and events based on a stale distribution snapshot stored on the correlation row rather than the live event access control list.
Because the correlation row's distribution columns are a point-in-time copy that lacks a published flag, the authorization check becomes incorrect when an event is subsequently restricted (for example, its sharing group is changed or it is unpublished). As a result, an authenticated user could retrieve attributes and event details belonging to events they no longer have permission to view.
Preconditions:
- An authenticated user with at least read access to some events in the instance.
- The existence of correlations between events, at least one of which has been restricted after the correlation was created.
Impact:
- Confidentiality: exposure of attribute values and event metadata that the user is not authorized to access.
Affected versions: MISP prior to v2.5.48. |
| MISP contains an authorization bypass in the related events listing functionality. When a user requests the list of events correlated to a given event, the system retrieved related event metadata directly from the correlation table without re-validating the caller's access rights against each related event.
The correlation table stores a snapshot of the event's distribution level and sharing group at the time the correlation was created, and does not carry the published flag. As a result, events that the caller is not permitted to open—because they are unpublished, or because their distribution or sharing group has changed since the correlation was recorded—were still returned with their metadata (title, date, correlating value counts).
Preconditions:
- An authenticated user with access to at least one event in MISP.
- The existence of correlation entries linking that event to other events the user should not be able to view.
Impact:
- Unauthorized disclosure of event metadata (titles, dates, correlation counts) for events the user has no right to access.
- Potential reconnaissance of threat-intelligence event names and timelines across sharing groups.
Affected: MISP versions prior to the fix commit (2ffa97f05). |
| The WP 2FA WordPress plugin before 4.1.0 does not invalidate a time-based one-time passcode once it has been used, allowing an attacker who knows an account's password and has observed a valid code within its validity window to replay it and bypass two-factor authentication, including on administrator accounts. |
| The MPG WordPress plugin before 4.2.3 does not validate that the dataset source supplied when importing a project is a remote URL before treating it as a local filesystem path and copying that file into a publicly accessible uploads folder. This makes it possible for users with the Editor role and above to read the contents of arbitrary files on the server, with the copied file then retrievable by unauthenticated visitors. |
| OpenAM before 16.1.3 contains an improper authorization vulnerability that allows delegated administrators to destroy sessions outside their realms because realm checks use the requester's realm. Authenticated accounts holding the iplanet-am-session-destroy-sessions attribute can supply a target session identifier or handle to forcibly log out users in any realm. |
| OpenAM before 16.1.3 applies its OAuth2 Provider PKCE enforcement only to authorization requests whose response_type is exactly code, so codes issued through OpenID Connect hybrid flows (code token, code id_token, code token id_token) carry no bound challenge. An attacker who intercepts such a code can redeem it for a public client's tokens with any non-empty code_verifier. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: preserve VFS inherited POSIX ACL mask
The VFS initializes a child's POSIX ACL from the parent's default ACL and
the requested creation mode. Do not mutate the parent ACL or overwrite the
child's VFS-computed access and default ACLs afterwards.
This preserves restrictive ACL_MASK entries and prevents SMB object creation
from widening effective permissions. |
| In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected. |
| In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key's identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it. |
| In SuperAGI v0.0.14 and prior, controller endpoints (/api/agents/create, /api/agents/schedule, /api/agents/delete, /api/agents/edit_schedule, /api/agents/stop_schedule) allow authenticated users from one organization to create, schedule, edit, stop, and delete agents belonging to a different organization's project. The endpoints accept a project_id parameter but do not verify that the project belongs to the authenticated user's organization. |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco IOS XE Software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities.
The vulnerabilities tracked by CVE-2026-20267 are related to improper access control issues that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-284. |
| TransformerOptimus SuperAGI v0.0.14 contains an incorrect access control vulnerability in delete_user_knowledge in superagi/controllers/knowledges.py. In affected source snapshots, POST /knowledges/delete/{knowledge_id} deletes the selected knowledge object without requiring authentication in the route and without verifying organization ownership of the supplied knowledge_id. |
| Ragflow 0.24.0 and prior contains improper access control in update_metadata_setting (api/apps/kb_app.py). Depending on the exposed entry, an attacker can perform unauthorized cross-session or privilege-crossing operations. |
