CVE Database

IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 may not enforce authorization correctly for some web servers.

IBM DataPower Gateway 10.5.0.0 through 10.5.0.22, 10.6.1 through 10.6.6, 10.6.0.0 through 10.6.0.10, and 11.0.0.0 through 11.0.0.2 could allow a remote attacker to bypass security restrictions due to improper authorization.

Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the repository's runners without an explicit approval.

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.

MISP contains an improper input validation vulnerability in the decaying model import functionality. The import endpoint was intended to create a new decaying model belonging exclusively to the importing user's organisation, with the default flag forced to off. However, the application stripped only the top-level id and uuid fields and pinned org_id and default on the outer array before saving the data flat. A user with decaying-model permissions could supply a nested model key carrying its own primary key, organisation identifier, and default flag, which bypassed those guards during the save operation. Impact: - A user with perm_decaying could overwrite an existing decaying model belonging to another organisation in place, altering its name, formula, parameters, or ownership. - A user could create or modify a model flagged as the organisation default, affecting scoring behaviour for other users. - A user could reassign a model's organisation to an arbitrary value. Preconditions: - Authenticated user with decaying-model permission (perm_decaying). - Network access to the MISP instance. Affected: <2.5.48.

MISP contains an authorization bypass in the event flattening feature. When a user requests an event with the flatten option enabled, the application removes the Object containment from the query and returns object attributes as top-level event attributes. In doing so, the object-level distribution and sharing-group access control check was not re-applied to those attributes. As a result, a user who can view a community-distributed event could retrieve attributes belonging to organisation-only objects (distribution level 0) or objects restricted to a specific sharing group, even though the user's organisation does not have access to those objects. This constitutes an unauthorized disclosure of sensitive threat intelligence data. A secondary issue was introduced by the initial remediation: the fix reused the full Object contain conditions (including soft-delete state) as the gate for flattened attributes, causing an event owner requesting deleted attributes to lose all attributes whose parent object was still live. The final fix isolates the distribution ACL condition as the sole gate. Preconditions: - An authenticated user with access to a community-distributed event - The event contains at least one object with a distribution level or sharing group that restricts access beyond the event's own distribution Impact: - Unauthorized disclosure of attributes belonging to restricted objects - Potential exposure of organisation-specific threat intelligence to other organisations Affected versions: <2.5.48