CVE-2026-44943: 
CBL Mariner 취약성 분석 및 완화

CVE-2026-44943 is a Path Traversal vulnerability (CWE-22) in open-iscsi that allows remote man-in-the-middle (MITM) attackers to create root-owned files outside the designated database directory and inject arbitrary lines into existing records. The vulnerability was discovered by Keith at Linneman Labs and publicly disclosed on July 29, 2026. It affects all versions of open-iscsi up to and including commit 668ca1df9c9a1e9bdd5c999ae1d67c9c8909237e. The CVSS v3.1 base score is 8.6 (High), and the CVSS v4.0 base score is 6.9 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is insufficient validation of IQN (iSCSI Qualified Name) target names received during iSCSI discovery. Open-iscsi uses target names as directory names within its database directory (typically /var/lib/iscsi), and prior to the fix, it accepted IQN names containing path traversal sequences such as ../../../* without sanitization. RFC 3722 Section 6.2 defines prohibited ASCII characters for IQN names — including forward slashes, backslashes, spaces, and control characters — but these were not enforced. A MITM attacker positioned between the iSCSI initiator and a discovery server could supply a crafted malicious target name containing traversal sequences, causing open-iscsi to create root-owned files at arbitrary filesystem locations and inject content into records outside the database directory. The fix introduces an iqn_name_valid() function that enforces RFC 3722 character restrictions across all discovery code paths (discovery.c, iscsiadm.c, iscsistart.c) (GitHub Commit, GitHub Advisory).

Successful exploitation allows a remote MITM attacker to write root-owned files to arbitrary locations on the filesystem and inject arbitrary content into iSCSI database records, resulting in a high integrity impact with a changed scope. While there is no direct confidentiality or availability impact, the ability to create or modify root-owned files outside the intended directory could facilitate privilege escalation, persistence mechanisms, or corruption of system configuration files. The attack is network-based, requires no authentication, and no user interaction, making it automatable against any system running a vulnerable version of open-iscsi that performs iSCSI discovery over an untrusted network (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.33%, indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to be positioned as a MITM on the network path between the iSCSI initiator and a discovery server, which limits opportunistic exploitation but is feasible in environments with inadequate network segmentation.

1. Reconnaissance: Identify target systems running open-iscsi that perform iSCSI discovery (e.g., via SendTargets or iSNS), particularly those on networks where MITM positioning is feasible (e.g., shared network segments, ARP spoofing opportunities).
2. MITM Positioning: Position between the iSCSI initiator and the discovery target/iSNS server using techniques such as ARP spoofing, DNS poisoning, or rogue iSNS server setup on the local network segment.
3. Craft Malicious Discovery Response: Intercept the iSCSI discovery response and inject a crafted target name containing path traversal sequences, e.g., iqn.2026-01.com.attacker:../../../etc/cron.d/backdoor or similar sequences using characters prohibited by RFC 3722 (e.g., forward slashes).
4. Trigger File Creation: When the vulnerable open-iscsi initiator processes the discovery response, it uses the unsanitized target name as a directory/file path within /var/lib/iscsi, causing root-owned files to be created at the traversed path outside the database directory.
5. Inject Content: Craft the discovery response payload to inject arbitrary lines into the created file, potentially writing malicious content (e.g., cron job entries, authorized_keys lines) to sensitive system locations (GitHub Commit, GitHub Advisory).

• File System: Unexpected root-owned files or directories created outside /var/lib/iscsi, particularly in sensitive locations such as /etc/cron.d/, /etc/sudoers.d/, /root/.ssh/, or other system directories; new files with timestamps correlating to iSCSI discovery activity.
• Logs: Entries in system logs (e.g., /var/log/syslog, /var/log/messages) showing open-iscsi processing target names containing path separator characters (/, \) or other RFC 3722-prohibited characters; iscsid log entries referencing unusual or malformed IQN names.
• Network: Unexpected or unauthorized iSCSI discovery responses (TCP port 3260) containing target names with path traversal sequences (../); ARP anomalies or unexpected hosts responding to iSNS or SendTargets discovery requests.
• Process: The iscsid daemon creating files in unexpected filesystem locations outside its normal database directory (/var/lib/iscsi).

Update open-iscsi to a version that includes commit 668ca1df9c9a1e9bdd5c999ae1d67c9c8909237e or later, which introduces IQN name validation enforcing RFC 3722 character restrictions across all discovery code paths (GitHub Commit). As a workaround, implement network segmentation to ensure iSCSI discovery traffic only traverses trusted network segments, and use network monitoring to detect anomalous iSCSI discovery responses. Verify the integrity of the /var/lib/iscsi database directory and surrounding filesystem locations for unexpected root-owned files. Avoid performing iSCSI discovery over untrusted or shared network segments until the patch is applied (GitHub Advisory, Red Hat Bugzilla).

The vulnerability was reported to the open-iscsi project by Keith at Linneman Labs and addressed alongside a related credential verification flaw (CVE-2026-44944) in the same commit. Red Hat has filed a high-severity bug report and is tracking the issue for affected products. SUSE has also acknowledged the vulnerability via their Bugzilla. No significant broader community or social media discussion has been observed beyond standard vulnerability database aggregation (Red Hat Bugzilla, GitHub Commit).