Habr•August 17, 2026•🇷🇺Translated from Russian

RCQ Messenger Duress PIN Flaw Gave Full Access to Real Database on Android

Developers of the open-source messenger RCQ published a detailed post-mortem on flaws in their duress PIN implementation. The feature, also known as panic PIN or decoy code, is intended to let users unlock a harmless version of the app when forced to hand over their device.

Both Android and iOS versions encrypt the local message database. The database key, called dataKey, is stored encrypted with a value derived from the user’s PIN using PBKDF2-HMAC-SHA256 with 400 000 rounds plus a platform-protected pepper. Multiple slots exist for the real PIN, the decoy PIN, and a wipe PIN; each slot was supposed to carry its own payload.

On Android the decoy slot originally stored the identical dataKey used by the real account. Hiding the second account was performed only by an in-memory filter, leaving the real .db files untouched on disk. Entering the decoy code therefore decrypted the genuine conversation history, giving the impression of protection while actually exposing everything.

The root cause traced back to an early design decision to make the decoy mode appear as a second legitimate account sharing the same database. Later analysis showed that server-side correlation via push tokens, IP addresses, and device identifiers would immediately link the two accounts anyway, rendering the shared-key approach both dangerous and unnecessary.

The iOS version avoided the shared-key mistake but introduced its own problem: activating decoy mode cleared contacts and groups, producing an obviously empty application that itself became evidence of concealment. Notifications also bypassed the decoy filter on both platforms, potentially revealing real incoming messages.

After the review the team adopted the iOS cryptographic model across platforms. The decoy slot now holds an independent random key that opens only a separate decoy database. This database is populated with locally generated, realistically dated conversations chosen by the user. No real network requests are possible from decoy mode, eliminating server-side linkage. Legacy slots are marked and require manual re-creation of the decoy PIN.

On desktop the Tauri application uses Argon2id (64 MB memory, 3 passes) to derive a key that encrypts a vault containing both account secrets and message history with AES-256-GCM. The web version deliberately offers no PIN protection because any script in the same origin can read localStorage and IndexedDB.

Related articles

Habr•Vulnerabilities & Exploits

Automating Asset Scanning in MaxPatrol VM via API: Part 4 on Authentication

A detailed technical guide explains how to build asset scanning automation in MaxPatrol VM using its API, starting with authentication methods. The author covers three authorization options including local account login-password, domain account credentials, and reference tokens, providing working Python examples for local accounts. Code reads secrets from an .env file and obtains a Bearer token valid for 24 hours from the Core role instance. The post details required privileges in both the Management Console and MaxPatrol 10 for tasks such as vulnerability exports, dynamic asset group management, scan task creation, and report exporting. It credits Alexey Leonov for an early GitHub script that enabled practical API usage and lists additional resources including webinars, SDK, CLI, Jira integration, and a Postman collection. All subsequent API calls rely on the generated headers containing the Bearer token.

Habr•Vulnerabilities & Exploits

Securing Hadoop Clusters: Removing Passwords from XML Configs with Credential Provider API and JCEKS

Hadoop configurations frequently expose sensitive credentials such as database passwords and cloud access keys in plain text within files like hive-site.xml and core-site.xml. The Credential Provider API, introduced in Hadoop 2.6, allows applications to retrieve secrets from an external JCEKS keystore instead of embedding them directly in XML. This mechanism uses conf.getPassword() to fetch decrypted values from the keystore when hadoop.security.credential.provider.path is configured. JCEKS relies on the outdated PBEWithMD5AndTripleDES algorithm, which remains vulnerable to Sweet32 attacks in theory though practical risk for small keystore files is low. Master password protection for the keystore itself is the weakest link, with options including environment variables, protected password files, or HDFS Transparent Data Encryption. Arenadata has automated credential encryption management in its ADH platform through ADCM to handle keystore creation, permission setting, and rotation across cluster nodes.

Security NEXT•Vulnerabilities & Exploits

CISA Adds Five Exploited Vulnerabilities to KEV Catalog Including AhsayCBS Authentication and Command Injection Flaws

The US Cybersecurity and Infrastructure Security Agency (CISA) has added five vulnerabilities to its Known Exploited Vulnerabilities catalog after confirming active exploitation in the wild. Four vulnerabilities were registered on October 14, 2026, and one additional entry followed on October 15. Among the newly listed issues are two critical flaws affecting the AhsayCBS backup management server: CVE-2026-105133, an authentication bypass in the API, and CVE-2026-105134, a command injection vulnerability in the replication feature. When chained together, the pair allows unauthenticated remote attackers to execute arbitrary operating system commands. Vendor Ahsay has released hotfixes in versions 10.3.4.45 and 9.15.2.70 because standard patches cannot fully address the issues. The advisory also references vulnerabilities in Atlassian products and multiple network security solutions from other vendors.

Security NEXT•Vulnerabilities & Exploits

Google Issues Chrome Security Update Fixing Critical Vulnerability Two Days After Previous Patch

Google has released a new set of security updates for its Chrome browser that address ten vulnerabilities, including one rated critical. The update arrives just two days after a larger patch that fixed 37 issues on October 13. The most severe flaw, tracked as CVE-2026-110922, is a use-after-free vulnerability in the Prerender feature that could allow remote code execution. The company released Chrome 155.0.8059.85 and 155.0.8059.84 for Windows and macOS, along with Chrome 155.0.8059.84 for Linux on October 15. The critical issue was reported by an external researcher on October 2. Deployment will occur gradually over the next several days to weeks.