| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Use after free in Microsoft QUIC allows an unauthorized attacker to disclose information over a network. |
| Data::MuForm::Localizer versions through 0.05 for Perl execute Perl from a message catalog header, reached at an arbitrary path because load_lexicon interpolates the language attribute into the catalog filename.
load_lexicon builds the catalog path by appending `Messages/$lang.po` to the directory holding Localizer.pm, where $lang is the language attribute, with no check that it names a bare locale tag. A value holding `../` segments walks out of the message directory, so any readable path with a `.po` suffix is loaded. While parsing the catalog, extract_header_msgstr takes the `Plural-Forms:` header, prefixes `$` to the bare words nplurals, plural and n, and passes the rest verbatim into a string that is evaluated: the nplurals form evaluates the header expression immediately, and the plural_code form compiles it into a subroutine whose body runs when a plural message is localized. A header of `nplurals=2; plural=(system('...'),0);` therefore runs that command as the catalog loads. The evaluation inherits strict, so an expression that assigns to an undeclared variable fails to compile, while one built from calls alone does not.
An application that sets the language attribute from request data, an Accept-Language header or a locale parameter, and an attacker who can place a file with a `.po` suffix and chosen contents at a readable path, together give code execution as the application user. The message expansion path is not affected: expand_named substitutes only the placeholder names the caller supplies, and _mangle_value returns the value unchanged. |
| Insufficient input sanitization in Snowflake Python API (`snowflake.core`) versions prior to 1.13.0 allowed confused-deputy privilege escalation through two related weaknesses: path traversal (CWE-22) via unencoded `..` identifier path segments, and HTTP parameter pollution (CWE-141) via unencoded `&`/`#`/`=` characters in query string values. An attacker with access to a downstream application built on snowflake.core could exploit the path traversal by supplying `..` as an object name, causing `snowflake.core` to issue REST requests against a parent resource or exploit the parameter pollution by injecting `&`/`#`/`=` into a free-form name field to override constraints on swap, clone, or rename operations — all executed under the application's privileged session. Successful exploitation requires the attacker to control an identifier or object-name string in an application built on snowflake.core that passes it to `snowflake.core` under a higher-privileged Snowflake session (e.g., an EXECUTE AS OWNER stored procedure, Streamlit app, or Native App). The fix is available in Snowflake Python API version 1.13.0, which also addresses several additional security findings. Users must manually upgrade. |
| Unauthenticated Broken Access Control in Taxi Booking Manager for WooCommerce <= 2.0.3 versions. |
| Unauthenticated Cross Site Scripting (XSS) in Business Directory <= 6.4.25 versions. |
| Unauthenticated Arbitrary File Deletion in Participants Database <= 2.7.8.4 versions. |
| Unauthenticated Cross Site Scripting (XSS) in GeekyBot <= 1.2.6 versions. |
| Unauthenticated Cross Site Scripting (XSS) in Visitor Traffic Real Time Statistics Pro <= 11.10 versions. |
| Subscriber SQL Injection in Visitor Traffic Real Time Statistics Pro <= 11.10 versions. |
| Unauthenticated Broken Access Control in SMEPay: UPI Gateway for WooCommerce <= 1.0.5 versions. |
| Unauthenticated Local File Inclusion in Barista <= 2.5.1 versions. |
| Unauthenticated Local File Inclusion in Foton Core <= 1.1.1 versions. |
| Unauthenticated Local File Inclusion in Biagiotti Core <= 2.1.1 versions. |
| Subscriber SQL Injection in Reviewer <= 3.14.2 versions. |
| Unauthenticated Server Side Request Forgery (SSRF) in Gutenverse Companion <= 2.5.1 versions. |
| Administrator SQL Injection in MailChimp For WooCommerce < 6.2 versions. |
| ** UNSUPPORTED WHEN ASSIGNED ** Deserialization of Untrusted Data vulnerability in Apache Shindig.
This issue affects Apache Shindig: all versions.
Users with access to the Shindig REST API can send specially-crafted requests to trigger arbitrary code execution on the server.
As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.
NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| AI_ONLY_REPORT
package: iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10
------
Summary: Stack Buffer Overflow in idbm_recinfo_config via Malicious iSCSI
Target: a crafted SendTargets TargetName can inject an extra configuration
line into a persisted node record and later cause a stack buffer overflow
when that record is reparsed.
Requirements to exploit: An attacker must control an iSCSI target or tamper
with SendTargets discovery traffic, return a crafted `TargetName`
containing a newline and oversized injected key or value data, have the
victim run persistent discovery, and then trigger a later node-record read
such as update or login.
Component affected: `iscsi-initiator-utils`;
`usr/idbm.c:idbm_recinfo_config`, with attacker-controlled input reaching
it through SendTargets handling in `usr/discovery.c` and later record
serialization in `usr/idbm.c`.
Version affected: `iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10`
Patch available: no released package fix established; proposed patch
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H - 7.5 (HIGH)
AV:N - The attacker can supply the malicious data over the network in a
SendTargets discovery response.
AC:L - The target-name length cap still leaves enough room for a newline
plus an overlong injected key; no race or unusual memory state is required.
PR:N - No prior access to the initiator is required.
UI:R - The victim must run SendTargets discovery that persists records
and later read the saved record.
S:U - The impact remains within the initiator-side component that parses
and stores its own database records.
C:L - Memory corruption could expose limited process memory, but
confidentiality impact is not demonstrated.
I:L - Process memory corruption can affect integrity, but reliable code
execution is not established.
A:H - The clearest supported outcome is a crash during config parsing.
Impact: Moderate. This issue could otherwise resemble an Important remote
denial-of-service flaw, but Red Hat rates such issues lower when they are
less easily exploited or depend on narrower conditions. Here, exploitation
requires a multi-step SendTargets discovery workflow, persistence of the
discovered record, and a later reread of that record. The strongest
supported outcome is denial of service or other memory corruption, while
code execution remains unproven.
Embargo: no
Reason: The available evidence supports a multi-step,
configuration-dependent denial-of-service or memory-corruption issue rather
than a demonstrated remote code execution flaw, so embargoed handling does
not appear necessary.
Acknowledgement: Aisle Research
Vulnerability Details: `idbm_recinfo_config()` copies config keys and
values into fixed stack buffers without bounds checks:
```c
while (*nl && !isspace(c = *nl) && *nl != '=') {
*(name+i) = *nl; i+; nl+;
}
...
while (*nl) {
*(value+i) = *nl; i+; nl+;
}
```
In this code path, `name` and `value` are 128-byte and 256-byte stack
buffers, so an injected key longer than 128 bytes or a value longer than
256 bytes can corrupt stack memory.
During SendTargets discovery, attacker-controlled `TargetName` text is
copied into the node record and later written back to disk without
control-character filtering:
```c
strlcpy(rec->name, targetname, TARGET_NAME_MAXLEN);
...
if (strlen(info[i].value))
fprintf(f, "%s = %s\n", info[i].name, info[i].value);
```
`process_sendtargets_response()` treats `TargetName=` records as discovery
input, and `add_target_record()` accepts names up to `TARGET_NAME_MAXLEN`.
That limit is 255 bytes in this package, which is still enough to carry a
newline plus a key longer than the 128-byte `name` buffer. A `TargetName`
such as `iqn.test\nAAAA...=B` can therefore split the serialized
`node.name` entry into two lines and inject a second config line.
Persistent SendTargets discovery stores discovered node records unless
nonpersistent mode is used, and later discovery update/login or explicit
node operations reread those saved records. The 2048-byte line buffer in
`idbm_recinfo_config()` does not prevent this because the injected line
only needs to exceed 128 bytes for the key or 256 bytes for the value.
Based on the available evidence, the supported impact is a crash or other
memory corruption during reparsing. Reliable code execution is plausible
but not established.
Steps to reproduce:
1. Run a malicious SendTargets responder, or intercept discovery traffic,
and return a `TargetName` value containing a newline and an oversized
injected key, for example `TargetName=iqn.test\nAAAAAAAA...(>=129 chars)=B`.
2. Run SendTargets discovery in its normal persistent mode. The default
`iscsiadm -m discovery ...` workflow persists records unless nonpersistent
mode is selected.
3. Inspect the saved node record and confirm that it contains both the
expected `node.name = ...` line and an injected `AAAA...=B` line.
4. Trigger any operation that rereads the node record, such as discovery
update, node update, or login.
5. Observe a crash during parsing. With instrumentation enabled, the
overflow should be reported in `idbm_recinfo_config()`.
Mitigation: Until a fix is available, avoid persistent SendTargets
discovery against untrusted or interceptable networks. Where operationally
acceptable, use nonpersistent discovery, and remove node records created
from untrusted discovery results before later update or login operations.
Proposed Fix: The fix should address both parts of the chain: bound the key
and value copies in `idbm_recinfo_config()` and reject control characters
in `TargetName` before persistence.
```diff
diff --git a/usr/idbm.c b/usr/idbm.c
@@ void idbm_recinfo_config(recinfo_t *info, FILE *f)
while (*nl && !isspace(c = *nl) && *nl != '=') {
*(name+i) = *nl; i+; nl+;
}
+ while (*nl && !isspace(c = *nl) && *nl != '=') {
+ if (i >= NAME_MAXVAL - 1) {
+ log_warning("Config file line %d key too long",
line_number);
+ break;
+ }
+ name[i++] = *nl++;
+ }
@@
while (*nl) {
*(value+i) = *nl; i+; nl+;
}
+ while (*nl) {
+ if (i >= VALUE_MAXVAL - 1) {
+ log_warning("Config file line %d value too long",
line_number);
+ break;
+ }
+ value[i++] = *nl++;
+ }
diff --git a/usr/discovery.c b/usr/discovery.c
@@ static int add_target_record(char *name, char *end, discovery_rec_t
*drec,
while ((nul < end) && (*nul != '\0'))
nul++;
+ for (char *p = name; p < nul; p++) {
+ if (*p == '\n' || *p == '\r' || (unsigned char)*p < 0x20) {
+ log_error("TargetName contains control characters,
rejecting");
+ return 0;
+ }
+ }
```
------
This report was generated using AI technology. Always review AI-generated
content prior to use |
| Use after free in Microsoft Office Word allows an unauthorized attacker to execute code locally. |
| Grav Plugin API (getgrav/grav-plugin-api) before 1.0.13 fails to enforce API-key scope caps in InvitationsController. The strip-super and accept-groups decisions are gated on a bare isSuperAdmin() check rather than a scope-aware permission check, so a least-privilege API key (scoped to api.users.write) minted on a super account can create an invitation record containing super-admin access flags. When the invitation is accepted, those flags are written verbatim to the new account, resulting in privilege escalation to a fully controlled super account. |
