Malicious backup archive upload in IBM QRadar could expose the underlying operating system

IBM QRadar 7.5.0 through 7.5.0 UP15 Interim Fix 002 could allow a privileged user to upload a malicious backup archive that could be restored and used to gain access to the underlying operating system.

• IBM QRadar: affected from 7.5.0 through and including 7.5.0 UP15 Interim Fix 002.
• Fix identified by IBM: IBM QRadar SIEM 7.5.0 UP15 IF03.
• The supplied record and reviewed advisory do not establish the status of other branches or parallel releases outside the stated range. Do not infer that every release after the fix has been verified as unaffected without corresponding confirmation.

The flaw is in IBM QRadar's backup archive upload and restore workflow. A privileged user can provide a malicious backup archive, which can then be restored and used to gain access to the underlying operating system. The attacker-controlled input is the backup archive content; the record does not disclose the archive format, the specific validation failure, or the exact mechanism that enables operating system access. The described path is network-reachable, has low attack complexity, and does not require additional user interaction. IBM classifies the weakness as CWE-530, while NVD also associates it with CWE-552 concerning files or directories accessible to external parties. The record contains conflicting privilege assessments, but IBM's description confirms that a privileged QRadar account is required.

• The attack path is reachable over the network and requires a privileged QRadar account to upload a backup archive.
• The record describes low attack complexity and no additional user interaction beyond the action performed by the privileged account.
• The supplied record sets public_exploit to false and does not identify an exploit, campaign, or specific victim. This is a record status, not proof that exploitation has never occurred.
• The known_exploited field does not confirm known exploitation. The exact minimum privilege level remains uncertain because the privilege assessments in the record conflict.

If exploited, a malicious backup archive could be used to gain access to the operating system underlying IBM QRadar. Possible technical consequences include reading data, modifying the system, or disrupting services, consistent with the described high impact to confidentiality, integrity, and availability. The initial condition is that the attacker must have permission to use the relevant functionality with privileges in QRadar, but the record does not identify the minimum role. The exact post-restore access scope, operating system privilege level, and persistence capability are not disclosed.

• An attacker who already has access to a privileged QRadar account could use a malicious backup archive to move beyond application data and reach the underlying operating system.
• That access could enable reading or changing data, modifying system configuration, or disrupting QRadar services.
• Because the flaw involves backup restoration, backup archives and recovery workflows should be treated as a specific area of risk during review.
• The record does not confirm a compromise, data loss, affected organization, or named attack campaign.

1. Update IBM QRadar SIEM 7.5.0 to 7.5.0 UP15 IF03, the specific fix identified by IBM.
2. Recheck the installed version after updating to confirm that the system is no longer within 7.5.0 through 7.5.0 UP15 Interim Fix 002.
3. Review backup archives uploaded or restored before patching, together with activity from the privileged accounts involved, to determine whether investigation is needed.
4. If an immediate update is not possible, contact IBM for deployment guidance. IBM's advisory does not specify a supported workaround or mitigation.
5. Do not treat access restriction or additional monitoring as a replacement for patching, because IBM does not confirm those measures as a workaround for this vulnerability.

1. Inventory IBM QRadar deployments and verify whether their installed versions fall within the affected range.
2. Review QRadar audit logs, where available, for backup archive upload or restore events performed by privileged accounts.
3. Compare uploaded and restored archives with approved change activity, especially when the archive source or contents are unexpected.
4. Review operating system access and activity logs on QRadar hosts around the time of relevant upload or restore operations.
5. Treat generic monitoring as a precaution only. The absence of a matching log event does not prove that a system is safe because the record does not establish which telemetry QRadar always records.