π¨ CVE-2026-14886
Vault Enterprise's identity entity batch-delete endpoint is vulnerable to a cross-namespace authorization bypass that may allow an authenticated caller in one namespace to permanently delete the storage backing of entities belonging to another namespace. This vulnerability (CVE-2026-14886) is fixed in Vault Enterprise 2.0.4, 1.21.9, 1.20.14 and 1.19.20.
π@cveNotify
Vault Enterprise's identity entity batch-delete endpoint is vulnerable to a cross-namespace authorization bypass that may allow an authenticated caller in one namespace to permanently delete the storage backing of entities belonging to another namespace. This vulnerability (CVE-2026-14886) is fixed in Vault Enterprise 2.0.4, 1.21.9, 1.20.14 and 1.19.20.
π@cveNotify
HashiCorp Discuss
HCSEC-2026-27 - Vault Enterprise vulnerable to cross-namespace entity deletion
Bulletin ID: HCSEC-2026-27 Affected Products / Versions: Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16 LTS, up to 2.0.3, 1.21.8, 1.20.13, and 1.19.19 LTS; fixed in Vault Enterprise 2.0.4, 1.21.9, 1.20.14 and 1.19.20. Publication Date: August 10,β¦
π¨ CVE-2026-18951
A flaw was found in the Red Hat OpenShift AI (RHOAI) overlay for the training operator. The RHOAI overlay incorrectly aggregates `trainjobs` management permissions into the native Kubernetes `edit ClusterRole`. This allows any user with `edit ClusterRole` permissions in a namespace to create, modify, and delete `TrainJobs`. When combined with a separate vulnerability (TRN-01) that permits arbitrary pod configurations, a remote attacker with namespace editor privileges could exploit this to escalate privileges, potentially leading to arbitrary code execution.
π@cveNotify
A flaw was found in the Red Hat OpenShift AI (RHOAI) overlay for the training operator. The RHOAI overlay incorrectly aggregates `trainjobs` management permissions into the native Kubernetes `edit ClusterRole`. This allows any user with `edit ClusterRole` permissions in a namespace to create, modify, and delete `TrainJobs`. When combined with a separate vulnerability (TRN-01) that permits arbitrary pod configurations, a remote attacker with namespace editor privileges could exploit this to escalate privileges, potentially leading to arbitrary code execution.
π@cveNotify
π¨ CVE-2026-42976
Missing authentication for critical function in Windows RPC API allows an authorized attacker to elevate privileges locally.
π@cveNotify
Missing authentication for critical function in Windows RPC API allows an authorized attacker to elevate privileges locally.
π@cveNotify
π¨ CVE-2026-50516
Missing authentication for critical function in Microsoft Azure Kubernetes Service allows an unauthorized attacker to elevate privileges over a network.
π@cveNotify
Missing authentication for critical function in Microsoft Azure Kubernetes Service allows an unauthorized attacker to elevate privileges over a network.
π@cveNotify
π¨ CVE-2026-54113
Allocation of resources without limits or throttling in Windows Kernel allows an unauthorized attacker to deny service over a network.
π@cveNotify
Allocation of resources without limits or throttling in Windows Kernel allows an unauthorized attacker to deny service over a network.
π@cveNotify
π¨ CVE-2026-59125
Use after free in Virtual Hard Disk (VHD) Miniport Driver allows an authorized attacker to elevate privileges locally.
π@cveNotify
Use after free in Virtual Hard Disk (VHD) Miniport Driver allows an authorized attacker to elevate privileges locally.
π@cveNotify
π¨ CVE-2026-59128
Out-of-bounds read in Windows Encrypting File System (EFS) allows an authorized attacker to disclose information locally.
π@cveNotify
Out-of-bounds read in Windows Encrypting File System (EFS) allows an authorized attacker to disclose information locally.
π@cveNotify
π¨ CVE-2026-59130
No cwe for this issue in AMD Zen allows an authorized attacker to disclose information locally.
π@cveNotify
No cwe for this issue in AMD Zen allows an authorized attacker to disclose information locally.
π@cveNotify
π¨ CVE-2026-59131
No cwe for this issue in AMD Zen allows an authorized attacker to disclose information locally.
π@cveNotify
No cwe for this issue in AMD Zen allows an authorized attacker to disclose information locally.
π@cveNotify
π¨ CVE-2026-65675
No cwe for this issue in Visual Studio Code CoPilot Chat Extension allows an unauthorized attacker to bypass a security feature over a network.
π@cveNotify
No cwe for this issue in Visual Studio Code CoPilot Chat Extension allows an unauthorized attacker to bypass a security feature over a network.
π@cveNotify
π¨ CVE-2026-18634
An insecure handling of serialized objects vulnerability was found in the one of the service of GMS application 9.5.1 (Build 9510.1044) and earlier versions. A local attacker with the ability to interact with the service could exploit this behavior to perform unauthorized actions through the affected component.
π@cveNotify
An insecure handling of serialized objects vulnerability was found in the one of the service of GMS application 9.5.1 (Build 9510.1044) and earlier versions. A local attacker with the ability to interact with the service could exploit this behavior to perform unauthorized actions through the affected component.
π@cveNotify
π¨ CVE-2026-18035
The User Access Manager WordPress plugin before 2.3.15 does not apply its access restrictions to REST API requests, allowing unauthenticated attackers to read the content of posts, pages and custom post types that have been restricted to specific user groups.
π@cveNotify
The User Access Manager WordPress plugin before 2.3.15 does not apply its access restrictions to REST API requests, allowing unauthenticated attackers to read the content of posts, pages and custom post types that have been restricted to specific user groups.
π@cveNotify
WPScan
User Access Manager < 2.3.15 - Unauthenticated Restricted Content Disclosure via REST API
See details on User Access Manager < 2.3.15 - Unauthenticated Restricted Content Disclosure via REST API CVE 2026-18035. View the latest Plugin Vulnerabilities on WPScan.
π¨ CVE-2026-68868
The Google Cloud Secret Manager secrets backend in Apache Airflow's Google provider never applied the team scope when resolving Connections and Variables: the caller's `team_name` was accepted by the backend but dropped at the internal call boundary, so every lookup resolved against the team-agnostic secret name. In a deployment running multi-team mode with this backend, a task or Dag belonging to one team resolved another team's Connection or Variable, obtaining its credentials in full. No unusual configuration is required beyond enabling multi-team mode and using this backend. Users are advised to upgrade to apache-airflow-providers-google 22.3.0 or later, which builds and applies the team-scoped secret name.
π@cveNotify
The Google Cloud Secret Manager secrets backend in Apache Airflow's Google provider never applied the team scope when resolving Connections and Variables: the caller's `team_name` was accepted by the backend but dropped at the internal call boundary, so every lookup resolved against the team-agnostic secret name. In a deployment running multi-team mode with this backend, a task or Dag belonging to one team resolved another team's Connection or Variable, obtaining its credentials in full. No unusual configuration is required beyond enabling multi-team mode and using this backend. Users are advised to upgrade to apache-airflow-providers-google 22.3.0 or later, which builds and applies the team-scoped secret name.
π@cveNotify
GitHub
Apply the team scope in the Google Secret Manager backend by potiuk Β· Pull Request #70869 Β· apache/airflow
CloudSecretManagerBackend.get_conn_value and get_variable both accept a
team_name, but the helper they delegate to has no such parameter:
def get_conn_value(self, conn_id: str, team_name: str | Non...
team_name, but the helper they delegate to has no such parameter:
def get_conn_value(self, conn_id: str, team_name: str | Non...
π¨ CVE-2026-18171
Docker Sandboxes (sbx) applies the read-only intent of a runtime host mount to the in-guest container bind only: the underlying virtio-fs host-edge grant is added to the sandbox's policy-share allowlist with no access mode. The directory stays writable at its shared-export path, so unprivileged code inside the sandbox can derive that path and write to a host directory the operator attached read-only.
π@cveNotify
Docker Sandboxes (sbx) applies the read-only intent of a runtime host mount to the in-guest container bind only: the underlying virtio-fs host-edge grant is added to the sandbox's policy-share allowlist with no access mode. The directory stays writable at its shared-export path, so unprivileged code inside the sandbox can derive that path and write to a host directory the operator attached read-only.
π@cveNotify
Docker Documentation
Docker Sandboxes
Run AI coding agents in isolated environments
π¨ CVE-2026-66380
An authenticated user without repository read permission may access private OCI referrer metadata under specific conditions.
π@cveNotify
An authenticated user without repository read permission may access private OCI referrer metadata under specific conditions.
π@cveNotify
Release Information
Artifactory Self-Hosted Releases
This section contains the Release Notes for Artifactory Self-Hosted releases.
π¨ CVE-2026-68752
A Project Resource Manager may gain broader administrative privileges under specific conditions.
π@cveNotify
A Project Resource Manager may gain broader administrative privileges under specific conditions.
π@cveNotify
Release Information
Artifactory Self-Hosted Releases
This section contains the Release Notes for Artifactory Self-Hosted releases.
π¨ CVE-2026-73374
A stored cross-site scripting (XSS) vulnerability existed in Vulnerability-Lookup in the render_tag_badges Jinja filter used to display reference tags associated with vulnerability records.
Values from containers.cna.references[].tags[] were directly interpolated into HTML badge elements and the resulting string was wrapped in markupsafe.Markup. Because Markup marks the generated content as safe, Jinja's automatic HTML escaping was bypassed.
An authenticated user with permissions to create or modify vulnerability records, such as a user holding the vulnerability:create or vulnerability:modify permission, could submit a crafted reference tag through the CNA API containing arbitrary HTML or JavaScript-capable markup.
The malicious value would subsequently be stored as part of the vulnerability record. When another user visited the corresponding public /cve/<id> or /vuln/<id> page, the crafted tag would be rendered as HTML in the viewer's browser. This could result in JavaScript execution in the security context of the Vulnerability-Lookup application.
Successful exploitation could allow an attacker to perform actions in the context of a victim, access information available to the victim's browser session, or modify page content. As the affected vulnerability pages can be accessed publicly, exploitation may affect users who are not authenticated.
The issue was corrected by applying markupsafe.escape() to each reference tag before inserting it into the HTML badge markup, while retaining Markup only for the static HTML scaffolding.
π@cveNotify
A stored cross-site scripting (XSS) vulnerability existed in Vulnerability-Lookup in the render_tag_badges Jinja filter used to display reference tags associated with vulnerability records.
Values from containers.cna.references[].tags[] were directly interpolated into HTML badge elements and the resulting string was wrapped in markupsafe.Markup. Because Markup marks the generated content as safe, Jinja's automatic HTML escaping was bypassed.
An authenticated user with permissions to create or modify vulnerability records, such as a user holding the vulnerability:create or vulnerability:modify permission, could submit a crafted reference tag through the CNA API containing arbitrary HTML or JavaScript-capable markup.
The malicious value would subsequently be stored as part of the vulnerability record. When another user visited the corresponding public /cve/<id> or /vuln/<id> page, the crafted tag would be rendered as HTML in the viewer's browser. This could result in JavaScript execution in the security context of the Vulnerability-Lookup application.
Successful exploitation could allow an attacker to perform actions in the context of a victim, access information available to the victim's browser session, or modify page content. As the affected vulnerability pages can be accessed publicly, exploitation may affect users who are not authenticated.
The issue was corrected by applying markupsafe.escape() to each reference tag before inserting it into the HTML badge markup, while retaining Markup only for the static HTML scaffolding.
π@cveNotify
GitHub
fix: [security] escape reference tags in render_tag_badges (XSS-VULN-01) Β· vulnerability-lookup/vulnerability-lookup@d299016
The tag_badges Jinja filter interpolated raw containers.cna.references[].tags[]
values into an HTML string and wrapped the result in Markup, bypassing Jinja
auto-escaping. Those tags are attacker-c...
values into an HTML string and wrapped the result in Markup, bypassing Jinja
auto-escaping. Those tags are attacker-c...
π¨ CVE-2026-73405
An authorization bypass vulnerability in Vulnerability-Lookup allowed inactive or unconfirmed accounts to subscribe to Server-Sent Events (SSE) streams through the /pubsub/subscribe/<topic> endpoint.
The token_required decorator used by the Pub/Sub interface authenticated requests solely by matching the X-API-KEY header against an existing user API key. Unlike the REST API authentication mechanism, it did not verify the account's is_active and is_confirmed state.
Because the self-registration process issues an API key before account confirmation is completed, an attacker could create an account and immediately use the resulting API key to access Pub/Sub topics that should only be available to active, confirmed users. This could expose stream events that would otherwise be inaccessible through the REST API, including newly submitted or not-yet-moderated data such as comments.
The vulnerability results from inconsistent authorization enforcement between the REST API and the SSE streaming interface.
The patch corrects the issue by requiring accounts to be both active and confirmed before permitting access to Pub/Sub streams, bringing the SSE authorization boundary in line with the REST API.
π@cveNotify
An authorization bypass vulnerability in Vulnerability-Lookup allowed inactive or unconfirmed accounts to subscribe to Server-Sent Events (SSE) streams through the /pubsub/subscribe/<topic> endpoint.
The token_required decorator used by the Pub/Sub interface authenticated requests solely by matching the X-API-KEY header against an existing user API key. Unlike the REST API authentication mechanism, it did not verify the account's is_active and is_confirmed state.
Because the self-registration process issues an API key before account confirmation is completed, an attacker could create an account and immediately use the resulting API key to access Pub/Sub topics that should only be available to active, confirmed users. This could expose stream events that would otherwise be inaccessible through the REST API, including newly submitted or not-yet-moderated data such as comments.
The vulnerability results from inconsistent authorization enforcement between the REST API and the SSE streaming interface.
The patch corrects the issue by requiring accounts to be both active and confirmed before permitting access to Pub/Sub streams, bringing the SSE authorization boundary in line with the REST API.
π@cveNotify
GitHub
fix: [security] gate SSE stream on active and confirmed account (AUTH⦠· vulnerability-lookup/vulnerability-lookup@bef8372
β¦-VULN-01)
The pubsub token_required decorator authenticated any user row whose apikey
matched the X-API-KEY header, without the account-state checks the REST API
gate (auth_func in website/web/ap...
The pubsub token_required decorator authenticated any user row whose apikey
matched the X-API-KEY header, without the account-state checks the REST API
gate (auth_func in website/web/ap...
π¨ CVE-2026-73431
Vulnerability-Lookup contains an
authentication weakness in its account activation and password-recovery
mechanism. Activation and recovery links were generated using stateless
signed tokens containing only the user's login. Although the token
signature and age were validated, the application did not track whether a
token had already been successfully used. As a result, a captured
activation or password-recovery link remained valid for the entire
configured TOKEN_VALIDITY_PERIOD, even after the associated password had been changed.
An attacker who obtains a valid
activation or recovery token could therefore replay it multiple times
during its validity period to set a new password and repeatedly take
control of the affected account. In addition, tokens were not bound to a
specific purpose, allowing the same token mechanism to be used across
activation and recovery workflows. The patch introduces purpose-bound
tokens and a random nonce whose SHA-256 digest is stored with the user
account. The nonce is invalidated after a successful password change,
making tokens single-use, while issuing a new token invalidates any
previously issued token. The password-setting operation now explicitly consumes the token before committing the account change.
Successful exploitation requires
the attacker to obtain a currently valid activation or recovery link,
but does not require knowledge of the victim's existing password or an
authenticated session.
π@cveNotify
Vulnerability-Lookup contains an
authentication weakness in its account activation and password-recovery
mechanism. Activation and recovery links were generated using stateless
signed tokens containing only the user's login. Although the token
signature and age were validated, the application did not track whether a
token had already been successfully used. As a result, a captured
activation or password-recovery link remained valid for the entire
configured TOKEN_VALIDITY_PERIOD, even after the associated password had been changed.
An attacker who obtains a valid
activation or recovery token could therefore replay it multiple times
during its validity period to set a new password and repeatedly take
control of the affected account. In addition, tokens were not bound to a
specific purpose, allowing the same token mechanism to be used across
activation and recovery workflows. The patch introduces purpose-bound
tokens and a random nonce whose SHA-256 digest is stored with the user
account. The nonce is invalidated after a successful password change,
making tokens single-use, while issuing a new token invalidates any
previously issued token. The password-setting operation now explicitly consumes the token before committing the account change.
Successful exploitation requires
the attacker to obtain a currently valid activation or recovery link,
but does not require knowledge of the victim's existing password or an
authenticated session.
π@cveNotify
GitHub
fix: [security] gate SSE stream on active and confirmed account (AUTH⦠· vulnerability-lookup/vulnerability-lookup@bef8372
β¦-VULN-01)
The pubsub token_required decorator authenticated any user row whose apikey
matched the X-API-KEY header, without the account-state checks the REST API
gate (auth_func in website/web/ap...
The pubsub token_required decorator authenticated any user row whose apikey
matched the X-API-KEY header, without the account-state checks the REST API
gate (auth_func in website/web/ap...
π¨ CVE-2026-73432
Vulnerability-Lookup contains a server-side request forgery (SSRF) vulnerability in the remote-instance synchronization functionality. Remote instance addresses were validated only for basic URL syntax before being stored, while the synchronization worker later dereferenced these addresses using requests.get() with automatic redirect handling and without enforcing network-boundary restrictions.
An authenticated administrator with the admin:access permission could configure a remote instance whose address points to an internal, loopback, link-local, or cloud metadata HTTP(S) service. When synchronization is performed, the Vulnerability-Lookup server would issue the request from its own network context. An attacker could also use a publicly accessible URL that redirects to an internal destination, because redirects were previously followed without revalidating the destination.
Successful exploitation could allow a privileged attacker to probe or interact with services that are accessible from the Vulnerability-Lookup server but not directly reachable by the attacker, including private network services or cloud instance metadata endpoints. The exact confidentiality, integrity, or availability impact depends on the services reachable from the application server.
The patch introduces a shared outbound URL policy that restricts remote instances to HTTP(S), rejects non-public IP addresses, resolves hostnames at request time, and manually validates each redirect destination before following it. The implementation explicitly blocks private, loopback, link-local, multicast, reserved, and unspecified addresses.
π@cveNotify
Vulnerability-Lookup contains a server-side request forgery (SSRF) vulnerability in the remote-instance synchronization functionality. Remote instance addresses were validated only for basic URL syntax before being stored, while the synchronization worker later dereferenced these addresses using requests.get() with automatic redirect handling and without enforcing network-boundary restrictions.
An authenticated administrator with the admin:access permission could configure a remote instance whose address points to an internal, loopback, link-local, or cloud metadata HTTP(S) service. When synchronization is performed, the Vulnerability-Lookup server would issue the request from its own network context. An attacker could also use a publicly accessible URL that redirects to an internal destination, because redirects were previously followed without revalidating the destination.
Successful exploitation could allow a privileged attacker to probe or interact with services that are accessible from the Vulnerability-Lookup server but not directly reachable by the attacker, including private network services or cloud instance metadata endpoints. The exact confidentiality, integrity, or availability impact depends on the services reachable from the application server.
The patch introduces a shared outbound URL policy that restricts remote instances to HTTP(S), rejects non-public IP addresses, resolves hostnames at request time, and manually validates each redirect destination before following it. The implementation explicitly blocks private, loopback, link-local, multicast, reserved, and unspecified addresses.
π@cveNotify
GitHub
fix: [security] enforce outbound-URL policy on remote-instance sync (β¦ Β· vulnerability-lookup/vulnerability-lookup@a3cf621
β¦SSRF-VULN-01)
Remote-instance addresses were validated for URL syntax only, then dereferenced
by the sync worker with requests.get() following redirects and with no network
boundary. An admin (ad...
Remote-instance addresses were validated for URL syntax only, then dereferenced
by the sync worker with requests.get() following redirects and with no network
boundary. An admin (ad...
π¨ CVE-2026-59242
Apache Airflow's XCom `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` endpoint passed a string-literal payload through `BaseXCom.deserialize_value` without the `_check_forbidden_xcom_keys` guard, allowing an authenticated API user with XCom write-and-read access to instantiate arbitrary `airflow.*` classes on the API server (CWE-502). An authenticated user who can write an XCom value and then read it back with `deserialize=true` triggers the unsafe instantiation. Users are advised to upgrade to apache-airflow 3.3.1 or later, which rejects reserved XCom serialization keys submitted as JSON string literals.
π@cveNotify
Apache Airflow's XCom `GET /api/v2/{...}/xcomEntries/{key}?deserialize=true` endpoint passed a string-literal payload through `BaseXCom.deserialize_value` without the `_check_forbidden_xcom_keys` guard, allowing an authenticated API user with XCom write-and-read access to instantiate arbitrary `airflow.*` classes on the API server (CWE-502). An authenticated user who can write an XCom value and then read it back with `deserialize=true` triggers the unsafe instantiation. Users are advised to upgrade to apache-airflow 3.3.1 or later, which rejects reserved XCom serialization keys submitted as JSON string literals.
π@cveNotify
GitHub
Reject reserved XCom serialization keys submitted as JSON string literals by potiuk Β· Pull Request #69378 Β· apache/airflow
The XCom create/update payload validator _check_forbidden_xcom_keys
recursively rejects reserved serialization keys (__classname__, __type,
__var, ...) in dict/list values. Its _walk helper descend...
recursively rejects reserved serialization keys (__classname__, __type,
__var, ...) in dict/list values. Its _walk helper descend...