CVE-2026-50749
Improper Authorization vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.1. Any authenticated user can reject
CVSS
—
No CVSS
EPSS
—
KEV
—
Exploit Today
—
0-100
Published: Aug 5, 2026 · Last modified: Aug 5, 2026 · CWE-863
Not enough EPSS history yet.
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.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-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.8hCVE-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.9hCVE-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.17hCVE-2026-55707——
——0In OpenStack Neutron before 28.0.2, the subnetpool onboarding API does not verify ownership of the target subnets. An authenticated user can onboard subnets from another project's shared network into their own subnetpool, mutating the victim's subnet state and altering L3 routing and address scope behavior for victim routers.17h