IBM Netezza Software CVE-2026-9745

Exploitation requires that the attacker identify or predict the name of an S3 bucket configured for use by IBM Netezza Software, and successfully register a bucket with that same name in a different AWS account - achievable if the bucket was previously deleted (bucket squatting) or if a naming collision exists across AWS regions. The target environment must be running IBM Netezza Software 11.3.0.3 through Interim Fix 002. No authentication to the Netezza system itself is required, but the attack is mediated through AWS S3 and therefore requires the attacker to have a valid AWS account to register the trap bucket. Exploitation is limited to versions with the missing ExpectedBucketOwner enforcement; environments with compensating IAM aws:ResourceAccount policies on their S3 buckets significantly reduce exposure even against unpatched versions.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, score 6.5) overstates ease of exploitation. AC:L implies low complexity, but successfully redirecting Netezza's S3 traffic requires the attacker to first discover the configured bucket name AND establish a same-named bucket in a different AWS account - prerequisites that constrain this to targeted, deliberate attacks rather than opportunistic mass exploitation. A more accurate characterization is AC:H. EPSS is not provided; no CISA KEV listing exists; no public exploit code is identified at time of analysis. Real-world risk is therefore moderate for environments where bucket names are predictable, previously deleted, or exposed via metadata/logs, and low for organizations with strict S3 naming hygiene. The integrity impact (data injection via attacker-controlled bucket) may actually be more operationally damaging than the confidentiality impact, yet the vendor tagging focuses only on information disclosure. This is primarily a supply-chain-style data integrity and exfiltration risk for data pipelines rather than a direct system compromise.

An attacker performing OSINT on a target organization identifies the name of an S3 bucket used by IBM Netezza (e.g., through CloudTrail exposure, metadata leakage, or predictable naming conventions). The attacker registers a bucket with the identical name in a separate AWS account, potentially after the original bucket lapses or in an exploitable region. When Netezza executes S3 write operations without the ExpectedBucketOwner parameter, misrouted requests deposit sensitive analytics data into the attacker's bucket, or the attacker stages malicious data in that bucket for Netezza to ingest. No public exploit code has been identified, but the attack technique is well-documented in AWS security literature on bucket squatting.