CVE Feed

vgmstream through r2117 contains a stack out-of-bounds read vulnerability in the G.722.1/Siren14 decoder in g7221_lib.c, whose bit reader refills without checking the data_u32 array end. Attackers can supply crafted .s14 or .sss files that drive decode_vector_quantized_mlt_indices() past the stack buffer during format detection, crashing the application.

ELFIO through 3.12 contains a NULL pointer dereference vulnerability in relocation_section_accessor get_entry() that allows attackers to crash applications via an unvalidated sh_link index. Attackers can supply a crafted ELF file whose SHT_REL or SHT_RELA section has a dangling sh_link, causing find_hash_section() to dereference null and deny service.

Sofia-SIP through 1.13.18 contains a heap out-of-bounds read vulnerability in msg_multipart_parse() that allows unauthenticated remote attackers to crash the process by sending oversized MIME boundaries. Attackers can send an INVITE with a multipart Content-Type whose boundary exceeds the body length, causing memcmp to read past the heap buffer and crash the process.

Khronos NNEF-Tools nnef through 1.0.10 and nnef-tools through 1.0.11 contain a path traversal vulnerability that allows attackers to write files outside the model directory via crafted variable labels. Attackers can supply a graph.nnef with '../' sequences or absolute paths in labels to create or overwrite '.dat' files when users convert, save, or generate weights.

miniupnpc through 2.3.3 contains a one-byte heap out-of-bounds read vulnerability in the minixml parseelt function's namespace-prefix handling that skips an end-of-buffer check after advancing past ':'. A malicious or spoofed UPnP gateway on the local network can send a device description or SOAP reply ending in ':' within an element name to crash the client.

miniupnpc through 2.3.3 contains a one-byte heap out-of-bounds read vulnerability in the minixml parseatt function that allows malicious UPnP gateways to read past buffer bounds via crafted replies. Attackers on the local network can spoof a gateway serving device descriptions or SOAP responses ending in '=' to crash the client.

libzvbi through 0.2.45 contains an out-of-bounds write vulnerability in the Teletext decoder that allows attackers to corrupt memory by supplying unvalidated DRCS pixel-mode values in X/28/3 packets. Attackers can send a crafted Teletext stream decoded via vbi_decode with every slot set to DRCS_MODE_6_5_4, causing convert_drcs to overflow chars[48][60] and crash the application.

A flaw was found in DPDK lib/vhost vhost-crypto. Session cleanup can leave a stale cached session pointer, and the data path does not check the session type before attaching it, leading to use-after-free or type confusion in the host vhost-crypto backend.

A flaw was found in DPDK lib/vhost. The VDUSE handler fails to invalidate vring pointers when the IOTLB is invalidated, leading to use-after-unmap.

A flaw was found in DPDK lib/vhost. A guest with runt RX descriptors can underflow the copy length in vhost enqueue, causing a denial of service in a shared vhost backend such as OVS-DPDK.

A flaw was found in DPDK lib/vhost. A guest can desynchronize virtqueue size from inflight descriptor table size, causing an out-of-bounds write in the host vhost process.

A flaw was found in DPDK lib/vhost. A double-offset bug in vhost log mapping calculation can lead to incorrect memory access.

A flaw was found in DPDK lib/vhost. A TOCTOU double-fetch of control-queue descriptors allows a heap buffer overflow with attacker-controlled content in the VDUSE control-queue handler.

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.31, 21.2.23, and 22.1.6, the @angular/platform-server DOM emulation parser can enter an infinite synchronous loop when Angular server-side rendering processes attacker-controlled HTML containing an incomplete DOCTYPE that ends with whitespace at end of input. In Domino lib/HTMLParser.js, after_doctype_name_state emits doctype and EOF tokens without advancing nextchar or leaving the fixed-lookahead state, so the scanner repeatedly handles the same EOF marker. A remote unauthenticated attacker can use this condition through server-side HTML parsing paths such as innerHTML binding to consume a Node.js SSR worker at full CPU, starve the event loop, and stop concurrent and subsequent requests. This issue is fixed in versions 20.3.31, 21.2.23, and 22.1.6.

A flaw was found in DPDK lib/vhost. Memory size is not adequately validated before mmap during vhost memory-region setup, which can lead to a host crash or memory corruption.

svg-sanitizer is a PHP SVG/XML sanitizer. Prior to 1.0.0, Resolver::processReferences() in src/ElementReference/Resolver.php builds the SVG <use> reference graph with a case-sensitive href attribute predicate before cleanHrefAttributes() normalizes mixed-case names. An attacker can provide xlink:HrEf on nested <use> elements so the graph omits those references, after which the sanitizer converts the attribute to canonical xlink:href and returns the live nesting structure without applying the useNestingLimit protection. A consuming application that renders the sanitized SVG can therefore be exposed to the resource exhaustion that control is designed to prevent. This issue is fixed in version 1.0.0.

util-linux is a random collection of Linux utilities. In util-linux 2.17 through 2.41.6 and 2.42 through 2.42.3, and in 2.42.4 when the legacy `mount(2)` path is used without `/proc`, restricted non-root `mount` requests validate an `/etc/fstab` target before the mount operation re-resolves that pathname. A local low-privileged user authorized by an fstab `user` or `users` entry whose target has an attacker-writable ancestor can use `renameat2(RENAME_EXCHANGE)` to swap a path component and redirect an authorized mount to a root-owned location, such as mounting attacker-controlled content over `/etc/sudoers.d`, and thereby gain root privileges. Versions 2.41.5 and 2.42.2 pin targets for the new mount API, and 2.42.4 pins legacy targets through `/proc/self/fd`; the documented legacy fallback without `/proc` remains affected.

util-linux is a random collection of Linux utilities. In util-linux 2.39 through 2.41.4 and 2.42 through 2.42.1, the SUID `mount` utility's `hook_owner.c` post-mount hook performs path-based `chmod()` and `lchown()` operations on a previously validated mount target. A local low-privileged user authorized by an `/etc/fstab` entry with `user` or `users` and an `X-mount.mode`, `X-mount.owner`, or `X-mount.group` option can use `renameat2(RENAME_EXCHANGE)` to race a writable ancestor of the target and redirect the privileged ownership or mode change to a root-owned path, potentially gaining root privileges. This issue is fixed in 2.41.5 and 2.42.2.

Description NGINX Ingress Controller has a vulnerability when implementing an externalAuth policy for ingress. NGINX Ingress Controller may mishandle the HTTP response from an OAuth IdP and allow an attacker to acquire unauthenticated access to protected paths before the proper external authentication can happen. Impact This vulnerability may allow remote attackers unauthenticated access to protected paths. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description NGINX JavaScript (njs) has a vulnerability where the njs XML module exposes entity-backed XML attributes inconsistently with libxml2 canonicalization. In both the built-in njs and QuickJS backends during the canonicalization process, the $attr$Name getter may return undefined for an explicitly present attribute containing an internal entity reference. The $attrs getter may return a value derived only from the first attribute child. This may allow an unauthenticated attacker that invests significant effort in obtaining a genuinely signed document to skip validation while signature verification succeeds. An nginx-saml deployment is a confirmed affected consumer when run with the built-in njs backend. Impact In affected signed-XML consumers, an unauthenticated attacker can cause security-relevant attributes to appear absent or truncated while signature verification succeeds. In nginx-saml, this can bypass expiry, Destination, and request-correlation checks, enabling replay or acceptance of a response outside its intended context. It does not permit signature or identity forgery, or a direct availability impact. There is no control plane exposure; this is a data plane issue only.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description NGINX JavaScript (njs) has a vulnerability where the built-in njs engine leaks a libxml2 parser context when xml.parse() fails. The failure path did not register cleanup and the context was not released for the lifetime of the process. An unauthenticated attacker may send requests with malformed XML and can cause unbounded memory growth in long-lived NGINX worker processes. Impact This vulnerability may allow remote attackers to send requests that trigger repeated parsing of malformed XML and may lead to NGINX worker termination or denial of service. There is no control plane exposure; this is a data plane issue only.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

An authentication and authorization bypass vulnerability exists in F5 NGINX Kubernetes Ingress Controller (NIC) when configured with the `ExternalAuth` policy or Ingress external authentication. Client-supplied X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI, and X-Forwarded-Method routing and method headers are forwarded unsanitized into the internal authentication subrequest (handled by the NGINX auth_request directive). As a result, an unauthenticated, remote attacker may spoof request attributes evaluated by the external authentication provider. Impact: This vulnerability may allow remote attackers unauthenticated access to protected paths. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description NGINX Gateway Fabric has a vulnerability when it is configured with Gateway Custom Resource Definition (CRD) and have an authenticated gRPC connection with NGINX Agent. A namespaced authenticated attacker with access to a service account may impersonate the authenticated NGINX Agent gRPC connection to read TLS private keys of Gateway deployments in another namespace.  Impact A remote authenticated attacker may be able to read TLS private keys of Gateway deployments in another namespace.  There is no data plane exposure; this is a control plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_v3_module module. When using HTTP/3 with proxy_request_buffering on directive, an unauthenticated attacker may be able to inject data in the proxied request. Impact This vulnerability may allow remote attackers to inject data in the proxied request.  There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description NGINX Gateway Fabric has a vulnerability when it renders the spec.basic.realm (and spec.jwt.realm) field of a namespaced AuthenticationFilter verbatim, unescaped and unvalidated, into the shared data-plane nginx.conf as auth_basic "<realm>";. A namespaced authenticated attacker that configures AuthenticationFilter CRD to an HTTPRoute/GRPCRoute on a shared Gateway can craft a realm value that closes the quoted directive and the enclosing location {} block and injects arbitrary NGINX directives into that Gateway's data-plane config.  Impact A remote authenticated attacker can send crafted requests to configure NGINX Gateway Fabric AuthenticationFilter CRD and may be able to read every co-located tenant's mounted secrets, SSRF via proxy_pass, reading the pod ServiceAccount token, or hijacking other tenants' routes. There is no data plane exposure; this is a control plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

A vulnerability exists in NGINX Plus and NGINX Open Source when a map directive uses regex matching and the root directive or access log format references the map's regex capture variables before referencing the map output variable. Alternatively, the same result could be achieved by using a non-cacheable variable in a string expression under certain conditions. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Impact:  This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_core_module module. When asynchronous file I/O (AIO) is enabled in certain configurations, processing a Server Side Includes (SSI) page containing “include virtual” commands may trigger a Use-After-Free (UAF) in the NGINX worker process. This may cause memory corruption or a worker process crash. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system, corrupt its memory, or possibly trigger code execution. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description When NGINX Plus or NGINX Open Source is configured with ssl_session_cache shared:name:size without an explicit ssl_session_ticket_key file directives to automatically rotate SSL session ticket keys, a remote unauthenticated attacker is able to forge client SSL sessions in a non-deterministic manner that is beyond the attacker's control. An attacker could leverage this vulnerability to bypass verification of client certificates. Impact This vulnerability can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with access to sensitive information. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

A vulnerability exists in NGINX Plus and NGINX Open Source when a location is configured that uses the alias directive together with rewrite and a set or return directive referencing the $request_filename variable. Alternatively, the same result could be achieved when the $request_filename variable is used in an access log format directive. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Gitea's web attachment handler skips its cross-repository ownership check for attachments created before 16 January 2026 and checks permissions against the repository named in the request URL instead. An unauthenticated attacker who knows a private attachment's UUID can request it through a public repository's attachment path and retrieve its contents. This can expose issue and pull request attachments or release assets; the random attachment UUID must already be known to the attacker.

When OpenID sign-in is enabled, Gitea processes unauthenticated assertion parameters and sends an HTTP POST request to the caller-supplied OpenID provider endpoint during verification. An attacker controls the destination and much of the form body, allowing interaction with internal HTTP services reachable from the Gitea server. The response is not returned to the attacker, so the issue is blind SSRF; its impact depends on the services and network addresses the server can reach.

Gitea's collaboration access-mode endpoint accepts the Owner access mode from an authenticated repository collaborator with Admin access. The collaborator can promote their effective permissions from Admin to Owner and then perform owner-only operations, including transferring the repository to their own account. This bypasses the intended boundary between repository administration and ownership.

Gitea allows a token with write:user scope to register an attacker-controlled SSH public key on the token owner's account. API requests signed with the corresponding private key authenticate as that account through HTTP Signature without API token scope information, causing route-level token scope checks to be skipped. This converts a user-scoped token into an unscoped API authentication method while retaining the account's normal role and repository permissions.

Gitea Runner passes workflow-controlled container options into Docker job container configuration while privileged mode is disabled. Host namespace settings, expanded capabilities, and security profile overrides can remain effective despite Privileged being forced false. A workflow author able to run jobs on an affected Docker-backed runner can use these options to access host namespaces and execute commands as root on the runner host, bypassing the intended container isolation.

Gitea resolves local reusable workflow files from a fork's head commit when a trusted base-branch workflow runs for a pull_request_target event. A fork author can modify a referenced reusable workflow so attacker-controlled code executes with the repository and organization secrets available to that event. Exploitation requires a base workflow that calls a local reusable workflow, and bypasses the intended separation between trusted base code and untrusted fork code.

Gitea substitutes a URL derived from the markup Context field into external renderer command templates without escaping the reference path before shell-style argument splitting. A crafted Context can inject additional renderer arguments, including options that load executable filter files. On deployments using a susceptible external renderer such as pandoc, a user who can place a filter file at an accessible path can cause it to execute as the Gitea service account; the public repository markup endpoint itself can be reachable without authentication.

Gitea's OpenID connect handler accepts a user's password without enforcing enrolled TOTP or WebAuthn verification before completing sign-in and linking an OpenID identifier. When OpenID sign-in is enabled, an attacker who knows the victim's password can obtain a session and link an attacker-controlled identifier. The attacker can then sign in through that identifier without the victim's password or second factor, and a password change does not remove the link.

Gitea's Maven upload handler reads checksum uploads entirely into memory and returns before enforcing package-size quotas. An authenticated user with package-publish permission can submit an oversized body to a checksum endpoint despite legitimate checksum values being at most 128 bytes. This bypasses the upload quota on that path and can exhaust server memory.

Gitea uses inconsistent repository visibility predicates, and the condition used by some repository-listing endpoints admits repositories whose owners are hidden from the viewer. Those listings disclose repository metadata even though direct routes correctly deny access with a 404 response. The issue exposes repository existence and listing information across the intended owner-visibility boundary.

Gitea does not limit the length of the gitignores field accepted by repository-creation forms and the API. Repository initialization splits the field into template names, repeatedly reads the referenced templates, and buffers their contents in memory. An attacker who can create repositories can submit an oversized value to amplify template reads and memory use, impairing availability.

Gitea's Actions workflow status badge endpoint does not enforce repository-read scope or the public-only restriction on the token authenticating the request. A token lacking read:repository, or restricted to public repositories, can retrieve the latest workflow status of a private repository accessible to its owner. This discloses private workflow status beyond the token's intended delegated permissions.

Gitea's repository markup endpoint resolves same-repository pull request references without enforcing the viewer's Pull Requests permission. A member with only Wiki access to a private repository can submit a markup preview request and retrieve a private pull request's title and state icon despite lacking Issues and Pull Requests access. This exposes pull request metadata across repository unit permissions.

Gitea's pull request review notifier does not attach the pull request to the Actions notification, so the fork workflow approval gate does not recognize the run as originating from a fork. Review comment and review approval or rejection events can consequently load workflow code from the fork head and run it on the base repository's runners without the required maintainer approval. This allows execution of fork-controlled workflow code across the intended approval boundary.

Gitea's organization-list API does not enforce the read:organization token scope. A token limited to another category, such as read:misc, can retrieve organization metadata visible to its owner. For a site administrator's token, the response can include Limited and private organizations, bypassing the intended restriction on the token's delegated access.

Gitea's shared comparison helper omits the token repository-access check used when updating pull requests. A public-only token with read:repository scope can route a comparison or pull request creation through a public base repository and retrieve commit history and diffs from a private head repository accessible to the token owner. This bypasses the token's public-only restriction; it does not remove the account's underlying repository permission checks.

Gitea creates server-side Git hook directories and scripts with mode 0777 and relies on the process umask to restrict access. With a permissive umask such as 0000 or 0002, another local user who can reach the repository storage may modify a hook or add an executable to a writable hook directory. A later Git operation can execute that file as the Gitea service account.

Gitea's repository migration API accepts a public-only token when the request specifies creation of a private repository. A delegated token intended to operate only on public resources can create a private repository and migration task under the authorizing account or an organization where that user has the necessary permissions. The ordinary private repository-creation route rejects the same token, but the migration path omits that restriction.

Gitea's organization repository-creation API requires write:organization but omits the write:repository token scope enforced by other repository-creation routes. A personal access token or OAuth application token without repository-write scope can therefore create organization-owned repositories if the authorizing user has permission to do so. This bypasses the token's delegated scope boundary while remaining subject to the user's organization permissions.

Gitea's user SSH and GPG key-list API endpoints omit the profile visibility check applied by their web equivalents. A restricted account can retrieve public keys, key titles, fingerprints, and GPG-embedded email addresses belonging to Limited-visibility users. The disclosure concerns public key material and associated metadata, not private cryptographic keys.

Gitea's API and web issue-search paths do not treat restricted accounts as anonymous viewers when evaluating Limited-visibility repository owners. A restricted user can search and retrieve issue titles and bodies that should be hidden by the owner's visibility policy. Keyword matching can also reveal that hidden issue content or comments contain a supplied term.