Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Your Azure SQL database contains business-critical data that drives operations, analytics, and customer experiences. Losing this data, even temporarily, can impede revenue, damage customer relationships, and create compliance problems. Learning how to back up an Azure SQL database is essential for business continuity.

At Tines, we recently faced a significant engineering challenge: our output_payloads table in PostgreSQL was rapidly approaching 17TB on our largest cloud cluster, with no signs of slowing down. Once a table reaches PostgreSQL’s 32TB table size limit, it will stop accepting writes. This table holds event data, in the form of arbitrary JSON, which is critical to powering Tines workflows. Given the criticality of the data, we couldn’t risk any disruptions to it.

MongoDB powers some of the world’s most modern applications.Everything from self-managed deployments to fully managed cloud environments run with MongoDB Atlas. But as teams scale across environments and projects, managing secure access becomes increasingly complex. Apono brings Just-in-Time, least-privilege access to MongoDB services across MongoDB, MongoDB Atlas, and MongoDB Atlas Portal.

A recent stack buffer overflow vulnerability in Redis, assigned CVE-2025-62507, was fixed in version 8.3.2. The issue was published with a high severity rating and assigned a CVSS v3 score of 8.8. According to the official advisory, “a user can run the XACKDEL command with multiple IDs and trigger a stack buffer overflow, which may potentially lead to remote code execution”.

Your Oracle database contains business-critical data that powers daily operations, customer transactions, and strategic decisions. Hardware failures, human errors, and ransomware attacks can destroy this data in seconds, stopping operations and costing you millions in recovery expenses and lost revenue. A proper Oracle database backup strategy determines whether your organization recovers quickly or faces extended downtime.

On December 12, 2025, the MongoDB Security Engineering team disclosed a high-severity vulnerability in MongoDB that allows unauthenticated memory disclosure. The issue is tracked as CVE-2025-14847 and has a CVSS score of 8.7 and was quickly nicknamed MongoBleed in the security community due to the way it exposes server memory.

CVE-2025-14847, nicknamed MongoBleed, is a high-severity (CVSS 7.5–8.7) unauthenticated information disclosure vulnerability in MongoDB Server. It allows remote attackers to leak uninitialized heap memory containing sensitive data—such as credentials, API keys, session tokens, and PII—without authentication. Exploitation occurs pre-authentication via malformed zlib-compressed network packets on port 27017.

On December 19, 2025, MongoDB issued an advisory for CVE-2025-14847, known as “MongoBleed,” a high-severity vulnerability in the server’s zlib-based network compression functionality. This vulnerability affects how the database handles compressed network communications and can cause it to accidentally leak sensitive information from its memory when abused by unauthenticated threat actors. The problem occurs when MongoDB receives a specially crafted message.

A newly disclosed MongoDB vulnerability, tracked as CVE-2025-14847 and informally referred to as MongoBleed, allows unauthenticated remote attackers to leak uninitialized memory from a MongoDB server. A public proof-of-concept exploit is already available, significantly increasing the risk for exposed MongoDB deployments. This post explains how the vulnerability works, what is required to exploit it, and how ARMO helps identify exposure and detect exploitation attempts at runtime.