CVE-2026-33460
Incorrect Authorization (CWE-863) in Kibana can lead to cross-space information disclosure via Privilege Abuse (CAPEC-122). A user with Flee
CVSS
4.3
Medium
EPSS
0.2%
p7
KEV
—
Exploit Today
2
0-100
Published: Apr 8, 2026 · Last modified: Jul 24, 2026 · CWE-863
0.2%EPSS · 30 days0.2%
2026-07-072026-08-04
Incorrect Authorization (CWE-863) in Kibana can lead to cross-space information disclosure via Privilege Abuse (CAPEC-122). A user with Fleet agent management privileges in one Kibana space can retrieve Fleet Server policy details from other spaces through an internal enrollment endpoint. The endpoint bypasses space-scoped access controls by using an unscoped internal client, returning operational identifiers, policy names, management state, and infrastructure linkage details from spaces the user is not authorized to access.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-50749——
———Improper Authorization vulnerability in Apache Answer.
This issue affects Apache Answer: through 2.0.1.
Any authenticated user can reject arbitrary pending edit-revisions without review permission due to a missing authorization check on the reject operation.
Users are recommended to upgrade to version 2.0.2, which fixes the issue.5hCVE-2026-712476.5 MED—
——0Documenso's sign-field-with-token.ts, used by the live document-signing UI, allows a recipient with the ASSISTANT role to fetch and complete fields belonging to any later-or-equal-order, not-yet-signed recipient in the same envelope, with no restriction on field type. The handler upserts a Signature record tied to the target field's recipientId with no check that field.type is SIGNATURE and the acting recipient owns it. A newer V2 signing path (sign-envelope-field.ts) explicitly blocks assistants from completing SIGNATURE fields, and the project's own test suite comments confirm this guard is absent from the V1 path used here. In a sequential-signing document, an assistant recipient can therefore forge another signer's signature field.9hCVE-2026-712347.5 HIG—
——0Documize Community's attachment download route (domain/attachment/endpoint.go, Download function, registered via AddPublic with no auth middleware) accepts a `secure` query parameter and grants access whenever the parameter is simply non-empty (len(secureToken) > 0), without comparing it to any server-stored value. Any non-empty string, such as ?secure=x, bypasses authentication entirely and allows downloading any organization's attachments. Sibling handlers in the same file (togglePublish, delete) correctly enforce session-based authorization, confirming this is an inconsistency rather than intended design.9hCVE-2026-712015.0 MED—
——0In OpenStack Ironic through 38.0.0, a project reader that makes a crafted request to Ironic can return Portgroups assigned to Nodes owned or leased by another project.7hCVE-2026-71192——
——0In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An
attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration.8hCVE-2026-71191——
——0In OpenStack Swift through 2.38.0, S3API middleware does not enforce that semantic x-amz-* headers are covered by the SigV4 signature on presigned URL requests. An attacker who obtains a presigned PUT URL can inject an unsigned X-Amz-Copy-Source header, causing Swift to perform a server-side copy from an arbitrary source object using the signer's authorization context. The attacker can read any object the signer has access to, provided the target project_id, container name, and object name are known. This affects all deployments using the default s3_acl=false configuration.16h