CVE-2026-107043 in Code Catcher
Summary
by MITRE • 10/29/2026
Insecure permissions in Code Catcher versionCode 131 allow unauthorized attackers to arbitrarily manipulate the app's SMS-code-capture mechanism.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in Code Catcher, specifically within application build or package code one hundred thirty-one, stems from a critical misconfiguration of file system and inter-process communication permissions. This flaw allows any other installed application on the same Android device to interact with the SMS-code-capture mechanism without proper authorization checks. In modern mobile operating systems, applications are typically sandboxed to prevent such cross-application interference. However, when an app declares overly permissive access controls or fails to enforce strict intent filters and permission requirements for sensitive components like broadcast receivers or content providers, it creates a pathway for unauthorized entities to inject data or manipulate the application's internal state.
The technical nature of this flaw involves the improper handling of incoming SMS interception intents or related system broadcasts that Code Catcher utilizes to capture one-time passwords or verification codes. By not restricting access to these components using signature-level permissions or explicit component visibility controls, the application inadvertently exposes its core functionality to any peer process on the device. An attacker can exploit this by crafting malicious applications that send forged SMS messages or intercept existing ones before they reach the legitimate system handler, thereby hijacking the authentication flow intended for Code Catcher users.
The operational impact of this vulnerability is severe, as it directly compromises the integrity and confidentiality of multi-factor authentication processes. Since Code Catcher is designed to capture verification codes sent via SMS, an attacker who successfully exploits these insecure permissions can intercept sensitive one-time passwords meant for legitimate users. This capability enables account takeover attacks, financial fraud if banking applications are targeted, or unauthorized access to personal accounts protected by two-step verification. The ability to arbitrarily manipulate the mechanism means that attackers do not just passively observe data but can actively alter the outcome of authentication attempts, potentially locking out legitimate users while gaining persistent access through compromised credentials.
Mitigation strategies must focus on enforcing strict least-privilege principles within the application's manifest and codebase. Developers should immediately review all exported components to ensure they are either non-exported or protected by custom permissions that require specific signatures from trusted applications only. Implementing explicit intent filters with appropriate permission attributes will prevent unauthorized apps from sending data to these endpoints. Additionally, integrating runtime checks for SMS reading permissions and validating the source of incoming broadcasts can provide an additional layer of defense against injection attacks. It is also advisable to update the application package version immediately to patch this exposure and advise users to uninstall any suspicious applications that may have been installed with malicious intent.
This vulnerability aligns closely with Common Weakness Enumeration category CWE-732, which describes excessive privileges granted to an actor or process. Furthermore, from a tactical perspective related to MITRE ATT&CK for Mobile, it falls under the technique of Intercepting SMS Messages and potentially relates to Privilege Escalation if the attacker leverages this access to gain higher-level system control. Addressing these issues requires not only code remediation but also rigorous security testing during the development lifecycle to ensure that sensitive data handling mechanisms remain isolated from untrusted third-party processes.