CVE-2024-35152 is a vulnerability identified in IBM Db2 for Linux, UNIX, and Windows version 11.5, including Db2 Connect Server. The issue arises from improper handling of memory allocation when processing certain crafted database queries, leading to uncontrolled memory allocation (CWE-789). An authenticated attacker with the ability to submit queries can exploit this flaw to cause a denial of service by exhausting system memory resources, potentially crashing the database server or severely degrading its performance. The vulnerability does not compromise data confidentiality or integrity but impacts system availability. The CVSS 3.1 base score is 6.5 (medium severity), reflecting the network attack vector, low attack complexity, required privileges, and lack of user interaction. No public exploits or active exploitation have been reported yet. The vulnerability was reserved in May 2024 and published in August 2024. IBM has not yet released a patch at the time of this report, so mitigation relies on access controls and monitoring. This vulnerability is significant for environments where IBM Db2 11.5 is deployed, especially in enterprise and mission-critical applications.

For European organizations, the primary impact is denial of service, which can disrupt business operations, especially in sectors relying heavily on IBM Db2 databases such as finance, telecommunications, and government services. A successful attack could lead to downtime, loss of productivity, and potential financial losses. While data confidentiality and integrity remain intact, the availability impact could affect service level agreements and damage organizational reputation. Organizations with multi-tenant environments or exposed database interfaces are particularly vulnerable. The medium severity rating indicates a moderate risk but should not be underestimated given the critical role of database availability in enterprise IT infrastructure.

1. Monitor IBM’s official channels for patches addressing CVE-2024-35152 and apply them promptly once available. 2. Restrict database access to trusted and authenticated users only, minimizing the attack surface. 3. Implement strict query validation and limit resource-intensive queries through database configuration or query governor features. 4. Employ network segmentation and firewall rules to limit access to the Db2 server from untrusted networks. 5. Monitor database logs and system metrics for unusual memory usage or query patterns indicative of exploitation attempts. 6. Consider deploying runtime application self-protection (RASP) or database activity monitoring (DAM) tools to detect and block malicious queries. 7. Educate database administrators and security teams about this vulnerability and ensure incident response plans include steps for DoS scenarios involving database services.