| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The BitPay Gateway for WooCommerce WordPress plugin through 4.1.3 does not bind the payment provider's transaction confirmation to the order it completes, nor verify the confirmed amount, allowing an unauthenticated attacker who holds a single genuine low-value transaction to mark arbitrary higher-value orders as paid. |
| The Sadad QA Payment WordPress plugin through 1.28 does not correctly verify the authenticity of incoming payment notifications, as the verification is keyed on a merchant secret that is empty by default and the rest of the signed data is attacker-controlled, allowing unauthenticated attackers to forge a valid confirmation and mark orders as paid without payment. |
| The Royal Elementor Addons WordPress plugin before 1.7.1070 does not validate submitted form field values before substituting them into the recipient addresses of its form notification emails, allowing unauthenticated attackers to replace the recipient list and relay attacker-composed email from the site's own domain when a recipient field is configured to echo a submitted value. |
| The Smart Popup by Supsystic WordPress plugin before 2.0.2 does not prevent template-injection payloads from being stored in a popup text block and later evaluated by its template engine, because the filter meant to strip template delimiters runs before a decoding step that reconstructs them, allowing an authenticated administrator to execute arbitrary template expressions server-side and read PHP constants such as the site's database credentials and authentication keys. |
| Link following vulnerability in Data Shredder components in Norton Antivirus, Avast Antivirus, and AVG Internet Security prior to 26.5.10933 on Windows allows a local, low-privileged attacker to escalate privileges to SYSTEM. During a privileged shred operation, enabling arbitrary file/folder deletion that is leveraged to gain NT AUTHORITY\SYSTEM privelages. |
| HCL BigFix AEX is affected by a Remote Code Execution Vulnerability . It may allow attackers to execute code with the privileges of the affected application or service, potentially leading to unauthorized access, data exposure, or system compromise. |
| HCL BigFix AEX is affected by an Unrestricted File Upload and Improper Access Control vulnerability. This could allow an attacker to upload malicious or unauthorized files and directly access or download sensitive uploaded content, potentially leading to information disclosure, unauthorized access, or system compromise. |
| HCL BigFix AEX is affected by an Information Disclosure vulnerability due to improper handling of errors or exceptional conditions. This could allow an attacker to obtain sensitive technical information, including stack traces, system details, or internal paths, potentially facilitating further attacks. |
| HCL BigFix AEX is affected by a Clickjacking vulnerability, which could allow an attacker to embed the application within a malicious web page or iframe and trick users into performing unintended actions, potentially leading to unauthorized transactions or changes to their accounts. |
| HCL BigFix AEX is affected by a Server-Side Request Forgery vulnerability, which could allow an attacker to cause the application to send unauthorized requests to external resources. Successful exploitation could lead to access to unintended services, sensitive information disclosure, or unauthorized actions through the affected application. |
| HCL BigFix AEX product is affected by a vulnerability in the aws-sdk package.. It may cause AWS API requests to be sent to unintended or non‐AWS endpoints. |
| Incorrect operator (CWE-480) in the FetchSnapshot RPC handler
in Apache Kafka from 2.8.0 before 4.2.2, and from 4.3.0 before 4.3.2
on all platforms allows an authenticated attacker with
CLUSTER_ACTION privilege to cause a denial of service
(controller process termination) via a crafted
FetchSnapshotRequest with an empty topics array or a topic
with no partitions.
Users are recommended to upgrade to version 4.2.2, 4.3.2, or
4.4.0, which fix this issue. Users on unsupported branches
(4.1.x and earlier) should upgrade to 4.2.2 or later. |
| A Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured:
- The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it.
- An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is
still rejected when no expected audience is configured.)
Both options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).
Impact:
The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token
minted for a different issuer, or a token lacking an audience, may be accepted to authenticate — potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss
claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the
signature is validated and only the issuer/audience checks are not enforced by default.
Mitigation (all affected versions, no upgrade required):
Set both sasl.oauthbearer.expected.issuer (to your provider's exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform
exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0.
Resolution:
- From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that
intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true. |
| An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can make a broker read a file or an environment variable from the broker host and return its contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource reaches the broker's configuration validation before any authorization check is applied to that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR} using a ConfigProvider named in the request, and this resolution bypasses the org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or EnvVarConfigProvider) is therefore instantiated and the referenced file or environment variable is read, and a type-validation error returns the resolved content to the caller.
Impact:
On a cluster with an authorizer enabled, an authenticated principal with no authorization grants can read the contents of files accessible to the broker process, and the broker's environment variables, exposing credentials, keystores, or other secrets, defeating the CVE-2024-31141 allowlist. The read is bounded by the broker process's file permissions. The brokers and the cluster remain available; the issue is disclosure of file and environment- variable contents. Clusters with no authorizer configured are not affected in practice, because every principal already holds ALTER_CONFIGS there.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a least-privileged operating-system account so that sensitive files are not readable by the broker process.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized (ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration- variable resolution enforces the config-providers allowlist. |
| HTTP::Body versions before 1.23_01 for Perl allow memory and temporary file exhaustion via an unlimited number of form fields and multipart parts.
The urlencoded parser splits the whole body on its separators at once, creating one scalar per separator before any field is stored. This costs about 90 bytes of memory per separator byte. The multipart parser creates a temporary file for every part that carries a filename. Neither parser limits how many fields or parts a body may hold.
A remote attacker can exhaust worker memory with a body made of separators, or create thousands of temporary files with one request of small file parts. |
| HTTP::Body versions before 1.23_01 for Perl leave the temporary file of an incomplete multipart upload on disk.
The multipart parser creates a temporary file as soon as a file part starts, but adds it to the upload list only when the part completes. Uploads are only ever deleted from that list, by the cleanup option or by the caller, so a body that ends inside a file part leaves its temporary file where nothing can find it.
A remote attacker can fill the temporary directory by repeating such requests, leaving one file behind for each. |
| HTTP::Body versions before 1.23_01 for Perl allow CPU exhaustion via quadratic rescanning of a multipart body with a missing or malformed boundary.
Before the first part, and between parts, the multipart parser searches the whole buffered body for the next boundary. On a miss it keeps everything and searches again from the start when the next chunk arrives. A body with no boundary, or with a delimiter followed by neither CRLF nor "--", is therefore rescanned on every chunk, taking time quadratic in its size.
A remote attacker can exhaust worker CPU with a few such requests. |
| HTTP::Body versions before 1.23_01 for Perl allow memory exhaustion via an unbounded multipart part header block.
The multipart parser takes everything up to the first blank line after a boundary as the part's header block, with no limit on its size or number of lines. Every line is stored in the part's header hash, so a block of short lines costs about 60 bytes of memory per input byte.
A remote attacker can exhaust worker memory with a single request. |
| HTTP::Body versions before 1.23_01 for Perl drop mixed-case percent escapes from urlencoded form fields instead of decoding them.
The decode table holds only the all-lowercase and all-uppercase spelling of each hex pair, while the escape pattern matches either case. An escape such as %aB finds no entry and is replaced with nothing, joining the bytes on either side. Hex digits in percent escapes are case-insensitive, and conforming decoders return the byte.
A remote attacker can send a field name or value that a conforming decoder in front of the application reads differently, so that pass%aBword reaches the application as password. |
| HTTP::Body versions before 1.23_01 for Perl allow CPU exhaustion via quadratic regex backtracking when parsing chunked request bodies.
In chunked mode, used when no content length is given, add() matches each chunk-size line with `/^([\da-fA-F]+).*\x0D\x0A/`. On a line of hex digits whose first LF has no CR before it, the digits and `.*` backtrack against each other, so a single add() takes time quadratic in the line's length. Nothing limits how long the line can be.
A remote attacker can exhaust CPU in applications that pass chunked request bodies to HTTP::Body. |
