CVE-2026-119736 in Attendo
Summary
by MITRE • 11/02/2026
Attendo (formerly Petpooja Payroll) Admin Android application version 3.0.13 and earlier contains a hard-coded credentials vulnerability that allows attackers to extract production MQTT broker credentials by decompiling the APK's bundled Flutter configuration assets such as production.json and device-command configuration files. Attackers can use the recovered credentials to authenticate to the production MQTT broker over TCP 1883, access messaging topics containing employee attendance records, personal identifiers, Base64-encoded photographs, device telemetry, and authentication material, and publish messages to those topics, resulting in exposure of sensitive data and potential unauthorized message injection.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Attendo, formerly known as Petpooja Payroll, specifically within the Android application version 3.0.13 and earlier versions, represents a critical failure in secure credential management practices. This flaw is classified under CWE-798: Use of Hard-coded Credentials, which denotes the use of static authentication credentials that are embedded directly into the source code or configuration files of an application rather than being dynamically generated or securely stored. In this specific instance, the vulnerability stems from the bundling of sensitive production MQTT broker credentials within Flutter configuration assets, such as production.json and device-command configuration files. These assets are packaged inside the Android Package Kit APK file, which is easily accessible to any user who installs the application on an Android device. The presence of these hard-coded secrets in client-side code violates fundamental security principles that dictate sensitive information should never be exposed to end-users or potentially malicious actors through reverse engineering techniques.
The technical mechanism exploited by attackers involves decompiling the APK file to extract the bundled configuration assets. Modern mobile applications, particularly those built with cross-platform frameworks like Flutter, often store configuration data in JSON files within the app bundle. When these files contain production-grade credentials without adequate obfuscation or encryption, they become trivial targets for static analysis tools and manual inspection. Once an attacker obtains access to the APK, typically through standard distribution channels or sideloading, they can decompress the archive structure and locate the specific configuration files mentioned. The extraction of the MQTT broker credentials from these plaintext JSON files allows the adversary to bypass any intended authentication barriers that might have been designed for mobile clients versus administrative interfaces, effectively granting them direct access to the backend messaging infrastructure.
The operational impact of this vulnerability is severe due to the nature of the data transmitted over the Message Queuing Telemetry Transport protocol on TCP port 1883. MQTT is commonly used in Internet of Things and enterprise mobility solutions for real-time communication between devices and servers. By authenticating with the stolen credentials, an attacker gains read access to various messaging topics that contain highly sensitive employee information. This includes detailed attendance records, personal identifiers such as names or identification numbers, Base64-encoded photographs which may include biometric data or identity documents, device telemetry logs that reveal hardware specifications and location data, and potentially other authentication materials used for session management. The exposure of this data constitutes a significant breach of privacy and could lead to identity theft, social engineering attacks against employees, or corporate espionage depending on the sensitivity of the collected information.
Furthermore, the vulnerability extends beyond passive data exfiltration to active manipulation capabilities. Because the attacker possesses valid credentials that authenticate as an authorized client within the MQTT broker architecture, they are not limited to reading messages but can also publish new messages to these topics. This capability aligns with ATT&CK technique T1530: Data from Cloud Storage and potentially T1498: Network Denial of Service if malicious payloads or disruptive commands are injected into the telemetry streams. Unauthorized message injection could lead to data corruption, false reporting of employee attendance, disruption of device management operations, or even triggering unintended actions on connected IoT devices if they process incoming MQTT messages without sufficient validation. The ability to inject messages undermines the integrity and availability aspects of the CIA triad, posing a risk not only to data confidentiality but also to system reliability and trustworthiness.
Mitigation strategies for this vulnerability must prioritize the removal of hard-coded credentials from client-side applications entirely. Developers should implement secure credential storage mechanisms provided by the operating system, such as Android Keystore or iOS Keychain, which encrypts sensitive data using hardware-backed security modules where available. For MQTT communication, it is essential to utilize dynamic token-based authentication rather than static username and password pairs that are baked into the application binary. If configuration files must be included in the app bundle for non-sensitive settings, they should never contain production secrets or private keys. Additionally, implementing certificate pinning can prevent man-in-the-middle attacks even if credentials were somehow compromised, although this does not replace the need to secure the initial authentication material. Regular security audits and static application security testing scans that specifically look for hard-coded passwords in configuration files are critical preventive measures. For organizations currently affected by this issue, immediate steps should include rotating all MQTT broker credentials associated with the mobile application, revoking any tokens issued under the compromised account, and releasing a patched version of the application that removes these sensitive assets from the public-facing APK bundle while enforcing stronger authentication protocols for future deployments.