CVE Feed

Nagios Core before 4.5.13 and Nagios XI before 2026R1.5 are vulnerable to authenticated remote code execution via custom-variable macro injection through the Nagios Remote Data Processor (NRDP). When a custom variable defined on a host, service, or contact is referenced in a shell-executed command line, an authenticated attacker with NRDP access can inject OS commands through the macro value. Exploitation requires a non-default configuration in which a custom variable is defined and referenced in a shell-executed command.

XSS vulnerability in Markdown handling in Apache Allura. This issue affects Apache Allura: from 1.10.0 before 1.19.1. Users are recommended to upgrade to version 1.19.1, which fixes the issue.

XSS vulnerability in code display in Apache Allura. This issue affects Apache Allura: before 1.19.1. Users are recommended to upgrade to version 1.19.1, which fixes the issue.

Insecure Direct Object Reference (IDOR) due to missing permission checks for multiple Artifact types in Apache Allura. This issue affects Apache Allura: before 1.19.1. Users are recommended to upgrade to version 1.19.1, which fixes the issue.

Specifically crafted inputs may lead to git argument injection in Apache Allura. This issue affects Apache Allura: before 1.19.1. Users are recommended to upgrade to version 1.19.1, which fixes the issue.

Nagios Core before 4.5.14 and Nagios XI before 2026R1.7 are vulnerable to DOM-based cross-site scripting in jsonquery.js. Unencoded JSON string values reflected from stored fields are inserted into the DOM without sanitization, allowing attackers to run arbitrary JavaScript in the victim's browser.

Nagios Core before 4.5.14 and Nagios XI before 2026R1.7 contain a cross-site request forgery protection bypass via a self-supplied double-submit cookie. An attacker can supply matching cookie and request parameter values to bypass CSRF protection, enabling unauthenticated attackers to run commands as authorized users via malicious links.

Microsoft UFO open-source framework for intelligent automation across devices and platforms. Prior to 3.0.8, _is_blocked_ip in ufo/utils/url_security.py did not block NAT64 prefixes 64:ff9b::/96 and 64:ff9b:1::/48, the 6to4 prefix 2002::/16, or the Teredo prefix 2001::/32 and did not re-check embedded IPv4 destinations, allowing an unauthenticated remote attacker who can influence URLs processed by validate_url to bypass the SSRF guard and reach cloud metadata, internal services, or localhost. This issue is fixed in version 3.0.8.

Nagios Core before 4.5.14 and Nagios XI before 2026R1.7 are vulnerable to reflected cross-site scripting in cmd.cgi via the NagFormId parameter. An unauthenticated remote attacker can craft a malicious link that, when followed by an authenticated user, executes arbitrary JavaScript in the victim's browser.

Microsoft UFO open-source framework for intelligent automation across devices and platforms. Prior to 3.0.8, create_mobile_data_collection_server and create_mobile_action_server in ufo/client/mcp/http_servers/mobile_mcp_server.py exposed Streamable HTTP MCP services on TCP ports 8020 and 8021 without authentication, allowing an unauthenticated remote attacker to invoke capture_screenshot, get_ui_tree, tap, swipe, type_text, launch_app, press_key, and click_control against an ADB-connected Android device, disclose screen and device data, and modify device state. This issue is fixed in version 3.0.8.

IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.8 is vulnerable to a privilege escalation when using Liberty collectives.

Material for MkDocs is a powerful documentation framework built on top of MkDocs. From 7.2.0 until 9.7.7, the mountSearchSuggest function in src/templates/assets/javascripts/components/search/suggest/index.ts contains a DOM-based cross-site scripting vulnerability in the optional search.suggest feature that allows a crafted q URL parameter to execute JavaScript in a documentation site's origin after user interaction. This issue is fixed in version 9.7.7.

Semaphore UI is a web interface for managing DevOps tools. Prior to 2.18.17 and 2.19.5-beta2, repository git_url handling passes an attacker-controlled --upload-pack option to CmdGitClient.GetLastRemoteCommitHash through POST /api/project/{id}/repositories and scheduled commit-hash polling, allowing a project Manager or Owner to execute arbitrary OS commands in the Semaphore server process. This issue is fixed in versions 2.18.17 and 2.19.5-beta2.

An unauthenticated user may access restricted artifacts in JFrog Artifactory under specific conditions.

Semaphore UI is a web interface for managing DevOps tools. Prior to 2.18.19 and from 2.19.0-alpha3 until 2.19.5-beta5, ProjectMiddleware and GetProjectOrGlobalRoleBySlug allow a project manager to use POST /api/project/{id}/roles to create a custom manager role with permission bitmask 15, overriding the built-in manager permissions and granting CanUpdateProject and CanManageProjectUsers owner capabilities. This issue is fixed in versions 2.18.19 and 2.19.5-beta5.

Apache Airflow's secrets masker did not mask `var.json` Variable values whose value is a dict in the Rendered Templates UI — the dict value failed an `isinstance(str)` guard — so a secret stored as a JSON Variable and referenced in a template via `var.json` was displayed in cleartext to any user with access to that task's Rendered Templates view. Users are advised to upgrade to apache-airflow 3.3.1 or later, which masks nested Variable values regardless of type.

Apache Airflow's serialization layer reconstructed exception nodes by calling `import_string()` on a class name taken from the serialized blob and instantiating it with arguments from the same blob, with no restriction on what could be imported. An operator's `executor_config` reaches that branch, so a Dag author could place a value there that causes an arbitrary callable to be imported and invoked -- for example `subprocess.check_output`, or `builtins.eval` on the `builtins`-prefixed variant. The code runs in the **Scheduler**, which reconstructs serialized Dags in its normal loop with no request involved, and in the **API server**, on any authenticated read of the Dag such as `GET /api/v2/dags/{dag_id}/details`. Both are components the Airflow security model states must never execute Dag-author code, and both hold the metadata database credentials and the JWT signing secret. No non-default configuration is required. This is a **different sink from CVE-2026-33264**, which covered only the trigger branch of the same deserializer: deployments that upgraded in response to that advisory are still affected through the exception branch and must upgrade again. Users are advised to upgrade to apache-airflow 3.3.1 or later, which restricts the imported class to a subclass of `BaseException`.

In Eclipse RDF4J, several XML parser entry points do not fully restrict XML External Entity (XXE) processing when parsing untrusted XML-based RDF data or query results, permitting DOCTYPE declarations, external entity references, and external DTD loading. This is due to an incomplete fix for CVE-2018-1000644: the earlier fix did not cover all parser entry points. The issue is resolved in RDF4J 5.3.2, which rejects or disables DOCTYPE declarations, external entities, and external DTD loading by default.

Fujitsu Research's OneCompression library before 1.2.1 contains an unsafe deserialization vulnerability that allows attackers to execute arbitrary code by supplying a crafted model.pt checkpoint file, as QuantizedModelLoader.load_quantized_model_pt() unconditionally calls torch.load with weights_only=False, invoking Python's pickle machinery during deserialization. Attackers can embed malicious __reduce__ methods in a crafted model checkpoint to execute arbitrary Python code, including system commands, when the library loads the file from a caller-selected model directory.

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.

Semaphore UI is a web interface for managing DevOps tools. Prior to 2.18.21, the /api/users/{id}/password endpoint accepts a cross-site request using the authenticated user's semaphore session cookie without CSRF protection or current-password confirmation, allowing an unauthenticated attacker to change an administrator's or another user's password after user interaction. This issue is fixed in version 2.18.21.

Apache Airflow's secrets masker hides values stored under sensitive key names when they are displayed in the UI. The masker's recursion-depth limit did not descend into values nested inside a list, tuple, or set beyond that limit, so an Airflow Variable holding such a deeply-nested value was shown unmasked in the Variables UI. The exposure is limited to the UI: any authenticated user who can see the Variable in the UI can already read its full value through the Variables REST API, so this does not disclose data the user could not otherwise obtain — the masking is a shoulder-surfing defense for the UI, not an access-control boundary. This is an incomplete-fix follow-up to CVE-2026-42358, whose fix made only the dictionary walk unbounded; lists, tuples, and sets beyond the depth limit remained unmasked in the UI. Deployments that applied the CVE-2026-42358 fix should also upgrade to address this residual case. Upgrade to apache-airflow 3.3.1 or later.

Apache Airflow 3.3.0 moved human-in-the-loop tasks from the triggerer to a new `awaiting_input` task state swept by the scheduler. That sweep deserializes the task instance's `next_kwargs` without an allow-list, so a Dag author — who controls that value through the task execution API — can cause an arbitrary module import and object instantiation inside the scheduler process, or terminate the scheduler job. No non-default configuration is required: the sweep runs unconditionally every 15 seconds, and the default `allowed_deserialization_classes` setting does not cover this code path. Versions before 3.3.0 are not affected, because human-in-the-loop tasks deferred onto the triggerer instead. This is a different code path from CVE-2026-58076, which covers the same unguarded exception-node deserialization reached elsewhere — deployments that applied that fix must upgrade for this issue as well. Users are advised to upgrade to apache-airflow 3.3.1 or later.

Apache Airflow's Task SDK rebuilt a `Callback` object from serialized data by re-running its constructor, which imports the module named by the stored callback path. Because `SyncCallback` is itself an Airflow class it passes the default `allowed_deserialization_classes` allow-list, so tightening that setting does not help. A Dag author — who controls a task instance's `next_kwargs` through the task execution API — can therefore cause an arbitrary module to be imported inside the scheduler process, when the scheduler's `awaiting_input` timeout sweep deserializes that value. No non-default configuration is required; the sweep runs unconditionally. Versions before 3.3.0 are not affected: the class existed, but the scheduler sweep that reaches it did not. This is a separate code path from CVE-2026-58076 and CVE-2026-67260, which cover different gadgets reaching deserialization — applying either of those fixes does not address this one. Users are advised to upgrade to apache-airflow 3.3.1 or later.

Incorrect database cloning process in Plesk from 18.0.52 before 18.0.79.6 and 18.0.80.2 allows a low-privileged user (customer, reseller) to execute arbitrary code on behalf of the database server administrator.

Apache Airflow's Config API did not mask team-scoped sensitive configuration values in multi-team deployments. When an administrator has enabled multi-team mode and exposed the Config API, an authenticated Viewer holding only configuration-read access — with no prior access to the secret — could read a team-scoped Celery broker URL, including its embedded credentials, in cleartext, while the equivalent global option was correctly masked. The secrets masker matched only base section and option names and did not normalize team-prefixed sections before the sensitivity check (CWE-200). This is a distinct masker bypass from CVE-2026-48828 and CVE-2026-48892: deployments that upgraded to apache-airflow 3.3.0 to address those issues remain affected by this team-scoped variant. Users are advised to upgrade to apache-airflow 3.3.1 or later, which normalizes team-scoped sections before masking.

Apache Airflow's Backfill API authorized a request against a Dag id supplied by the caller whenever the `backfill_id` path segment failed to parse. The authorization dependency parsed it with `int()` while the route handler parsed it as pydantic's `NonNegativeInt`, which accepts values `int()` rejects (`1.0` coerces to `1`); FastAPI resolves dependencies before endpoint validation, so the two acted on different Dags. An authenticated user holding edit permission on any single Dag could therefore read, pause and cancel backfills belonging to any other Dag, including moving another Dag's queued runs to `failed`. No non-default configuration is required and backfill ids are sequential, so finding a target is trivial. Users are advised to upgrade to apache-airflow 3.3.1 or later, which parses the backfill id with the same type the routes declare.

Apache Airflow wrote Variable values and Connection `extra` contents to the audit log in cleartext when they were submitted through the bulk endpoints (`PATCH /api/v2/variables` and `PATCH /api/v2/connections`). The audit-log masking recognised only top-level request fields, and a bulk request nests its entities two levels below, so no masking was applied to them. Any authenticated user with audit-log read access -- who need not hold Variables or Connections read at all -- could recover those secrets verbatim, and the Connection `extra` copy is stored unencrypted in the log while the connection table encrypts it. The Airflow UI's *Import Variables* action posts to this endpoint, so an ordinary operator import wrote every secret in the file to the log. This is a different code path from CVE-2026-50204: that fix shipped in 3.3.0 and covers the single-entity endpoints only, so deployments that upgraded in response to that advisory remain affected and must upgrade again. Users are advised to upgrade to apache-airflow 3.3.1 or later.

Apache Airflow's Task SDK did not mask the contents of a Variable whose JSON value is a list, so secrets stored in that shape appeared in cleartext in task logs and in the Rendered Templates UI. Masking was applied only when the deserialized value was a string or a dict; a list at the top level matched neither and was returned unmasked. Any authenticated user able to read the logs or rendered templates of a task that references such a Variable could recover the values, with no special configuration required. This is the list-shaped counterpart of CVE-2026-59244, whose fix covered the dict case only, so deployments that upgraded in response to that advisory remain affected and must upgrade again. Users are advised to upgrade to apache-airflow 3.3.1 or later.

Apache Airflow's asset materialization endpoint (`POST /api/v2/assets/{asset_id}/materialize`) and the XCom result check on `wait_dag_run_until_finished` authorized the target Dag without its team, unlike every other authorization site. A team-aware auth manager distinguishes a team-scoped Dag from a global one by that field -- the Keycloak auth manager, for example, checks the `DAG` resource instead of `DAG:<team>` -- so the team-scoped permission that should gate the request was never consulted. In a deployment running multi-team mode with a team-aware auth manager, an authenticated user in one team could trigger Dag runs belonging to another team, supplying their own `dag_run_id` and `conf`, and could read another team's XCom values. Deployments using the FAB auth manager are unaffected, as it has no multi-team support. Users are advised to upgrade to apache-airflow 3.3.1 or later, which resolves the Dag's team at both sites.

In WhatsUp Gold versions released before 2026.0.2, an unauthenticated remote attacker with network access to the affected service can execute arbitrary code in the context of the IIS application service account.

In WhatsUp Gold versions released before 2026.0.2, a privileged attacker can write arbitrary files to a web-accessible location on the host server.

Apache Airflow's environment-variable secrets backend resolved a team-scoped Connection or Variable from the wrong team's scope. The guard meant to prevent this only ran when no team scope was supplied, and its pattern could not match a team name containing an underscore, which team names are allowed to contain. When the guard did not apply, the lookup fell through to an unconditional global read that resolved the stored `AIRFLOW_CONN__<TEAM>___<ID>` variable regardless of which team asked. In multi-team mode an authenticated user of one team could therefore have `POST /api/v2/connections/test` resolve another team's Connection and authenticate outward with that team's credentials; the endpoint uses the credentials rather than returning them. Exploitation requires `[core] multi_team` enabled, `[core] test_connection` set to `Enabled` (it ships `Disabled`), team-scoped secrets provisioned as environment variables in the API-server process, and knowledge of the encoded identifier. Redirecting the test at an attacker-controlled host is separately blocked. Users are advised to upgrade to apache-airflow 3.3.1 or later.

In WhatsUp Gold versions released before 2026.0.2, a privileged attacker can create a LogToFile action specifying an arbitrary file extension within the IIS web root.

In WhatsUp Gold versions released before 2026.0.2, an improper authorization vulnerability in the Scheduled Reports API allows any authenticated user to invoke restricted actions.

In WhatsUp Gold versions released before 2026.0.2, an authenticated attacker can bypass frontend controls and inject persistent script content.

AI_ONLY_REPORT package: iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10 ------ Summary: Out-of-Bounds Write and Information Disclosure via Unvalidated IPv6 Payload Length: crafted ICMPv6 Echo Requests can cause `iscsiuio` to trust an inflated `ipv6_plen` larger than the actual received payload, leading to MTU-bounded out-of-bounds reads and a potential one-byte out-of-bounds write that may disclose data beyond the valid packet boundary. Requirements to exploit: Adjacent-network access on the same L2 segment as a system running `iscsiuio` on an interface that processes IPv6/NDP traffic, plus the ability to send a crafted ICMPv6 Echo Request with a forged `IPv6.plen`. No authentication or user interaction is required. Component affected: `iscsi-initiator-utils` (`iscsiuio`): `iscsiuio/src/uip/ipv6.c` in `ipv6_icmp_handle_echo_request()` and `ipv6_insert_protocol_chksum()`. Version affected: `iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10` when `iscsiuio` is processing IPv6/NDP traffic on a reachable interface. Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L - 6.3 (MEDIUM) AV:A - Reachability is limited to an attacker on the same L2 segment who can send crafted IPv6/ICMPv6 traffic to the affected interface. AC:L - The attack relies on forging `IPv6.plen`; no race or unusual environment is needed beyond the vulnerable deployment. PR:N - No privileges are required. UI:N - No user interaction is required. S:U - The impact remains within the `iscsiuio` process and its packet buffer handling. C:L - The reply/checksum path can read and potentially transmit data beyond the valid packet boundary, but the demonstrated exposure is MTU-bounded. I:L - For odd forged lengths, the checksum path can write a single padding byte past the valid protocol data, which may affect adjacent buffer contents. A:L - Invalid memory access may destabilize or crash the process, but reliable high-impact denial of service is not established from the available evidence. Impact: Moderate. Under Red Hat's severity guidance, this is more consistent with a flaw that can affect confidentiality, integrity, or availability under constrained circumstances than with an Important issue. The bug is unauthenticated and adjacent-network reachable, but the currently supported outcome is MTU-bounded out-of-bounds access in a deployment-dependent IPv6/NDP path, not easy remote system compromise or clearly high-impact memory corruption. Embargo: no Reason: The currently supported impact is Moderate, exposure depends on `iscsiuio` processing IPv6 traffic on a reachable L2 segment, and operators can reduce exposure operationally by isolating or disabling the affected path. Acknowledgement: Aisle Research Vulnerability Details: In the ICMPv6 echo-reply path, the code reuses the inbound `ipv6_plen` field when sizing the reply instead of clamping it to the bytes actually received: ```c /* iscsiuio/src/uip/ipv6.c */ static void ipv6_icmp_handle_echo_request(struct ipv6_context *context) { ... ipv6_send(context, (u8_t *) icmp - (u8_t *) eth + sizeof(struct ipv6_hdr) + HOST_TO_NET16(ipv6->ipv6_plen)); } ``` Later, checksum generation also trusts `ipv6_plen` for memory traversal, and for odd lengths it writes a padding byte at `ptr + protocol_data_len` before iterating over `protocol_data_len` bytes: ```c /* iscsiuio/src/uip/ipv6.c */ protocol_data_len = HOST_TO_NET16(ipv6->ipv6_plen); ... if (protocol_data_len & 1) { *((u8_t *) ptr + protocol_data_len) = 0; protocol_data_len++; } for (i = 0; i < protocol_data_len / 2; i++) { sum += HOST_TO_NET16(*ptr); ptr++; } ``` The available receive-side logic does not establish a payload-length bound strong enough to eliminate this condition. `uip_input()` compares the IPv6 payload length against `uip_len`, but `uip_len` is treated as full frame length in the observed path rather than the actual IPv6 payload length, and `ipv6_rx_packet()` receives a `len` argument without using it to bound parsing. A forged `ipv6_plen` can therefore exceed the real IPv6 payload stored in the buffer. The available evidence supports MTU-bounded out-of-bounds access in normal receive paths rather than the earlier arbitrary 64KB worst case. The affected logic appears to be present in the available 6.2.1.11 code base, but this report is scoped to the scanned SRPM package. Steps to reproduce: 1. Build `iscsiuio` with ASAN enabled. 2. Run `iscsiuio` with IPv6/NDP active on a test interface. 3. From the same L2 segment, send an ICMPv6 Echo Request with `IPv6.plen` set larger than the actual payload bytes in the frame buffer; one tested shape is `plen=1491` with an Ethernet frame size near 1500 bytes. 4. Observe the reply path: ASAN reports invalid access in `ipv6_insert_protocol_chksum()` as the checksum walk reads past valid packet data, odd lengths may also trigger a one-byte write, and reply sizing is derived from the forged `ipv6_plen` rather than the actual received payload size. Mitigation: Until a fix is available, keep `iscsiuio`-managed interfaces on trusted L2 segments only. Where operationally acceptable, disable IPv6 on those interfaces or filter ICMPv6 Echo Requests before they reach `iscsiuio`. If `iscsiuio` is not processing IPv6/NDP traffic, this specific path is not reachable. Proposed Fix: Clamp the reply payload length to the actual received payload derived from `context->ustack->uip_len`, reject packets too short to contain a complete ICMPv6 header, and rewrite `ipv6->ipv6_plen` before calling `ipv6_send()`. ```diff diff --git a/iscsiuio/src/uip/ipv6.c b/iscsiuio/src/uip/ipv6.c @@ -1100,6 +1100,8 @@ static void ipv6_icmp_handle_echo_request(struct ipv6_context *context) { struct eth_hdr *eth = (struct eth_hdr *)context->ustack->data_link_layer; +u16_t rx_total, rx_payload, hdr_plen, safe_plen; +u16_t l2_l3_len = sizeof(struct eth_hdr) + sizeof(struct ipv6_hdr); struct ipv6_hdr *ipv6 = (struct ipv6_hdr *)context->ustack->network_layer; struct icmpv6_hdr *icmp = (struct icmpv6_hdr *)((u8_t *)ipv6 + @@ -1126,8 +1128,20 @@ static void ipv6_icmp_handle_echo_request(struct ipv6_context *context) icmp->icmpv6_code = 0; icmp->icmpv6_cksum = 0; ILOG_DEBUG("IPv6: Send echo reply"); -ipv6_send(context, (u8_t *) icmp - (u8_t *) eth + sizeof(struct ipv6_hdr) + HOST_TO_NET16(ipv6>ipv6_plen)); + +rx_total = context->ustack->uip_len; +if (rx_total <= l2_l3_len) +return; + +rx_payload = rx_total - l2_l3_len; +hdr_plen = HOST_TO_NET16(ipv6->ipv6_plen); +safe_plen = (hdr_plen <= rx_payload) ? hdr_plen : rx_payload; +if (safe_plen < sizeof(struct icmpv6_hdr)) +return; + +ipv6->ipv6_plen = HOST_TO_NET16(safe_plen); +ipv6_send(context, l2_l3_len + safe_plen); + return; } ``` ------ This report was generated using AI technology. Always review AI-generated content prior to use

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

An unauthenticated attacker may cause untrusted package content to be cached under specific conditions, potentially affecting artifact integrity and availability.

An authenticated user without repository read permission may access package metadata under specific conditions.

Under specific self-hosted Helm configurations, generated TLS private keys may be retained in rendered manifests accessible to highly privileged local users.

A holder of a valid integration credential may impersonate other users under specific conditions.

An anonymous caller when anonymous access is enabled, or a low-privilege authenticated user, may learn private Release Bundle names and versions when the bundle name is known.

An authenticated user may write data outside the intended Docker cache path under specific remote-repository conditions.

A low-privileged authenticated user may access restricted support information under specific conditions.

A low-privilege authenticated user may permanently remove protected internal metadata across repositories under specific conditions.

A user with access to a valid SAML response may impersonate another user under specific conditions.

A party with write access to stored session data may affect JFrog Artifactory under specific conditions.

An authenticated user may write files outside the intended Artifactory work directory under specific conditions.

A repository reader with cache-deploy permission may access content outside a configured upstream path under specific conditions.