CVE-2026-34490: XAAP Android 1.53 Fixes Cleartext Data Exposure

Johnson Controls has issued a security fix for XAAP Android, addressing a local data exposure weakness that could allow sensitive application information to be read in plaintext from an affected device. The issue, tracked as CVE-2026-34490, affects XAAP Android versions earlier than 1.53 and has been assigned to the CWE-312 Cleartext Storage of Sensitive Information category. Organizations using the Fire Solutions Android application should treat version 1.53 or later as the minimum safe release and make deployment verification a priority.
The vulnerability is not remotely exploitable, does not provide an attacker with a direct route into a corporate network, and has not been linked to publicly reported exploitation. Those details matter. They also do not make the issue irrelevant. In operational environments, an Android device is often a portable endpoint containing site-specific data, service records, configuration context, session information, or material that can help an attacker understand a facility and its systems.
For Windows administrators, security teams, and IT departments supporting mixed Windows and Android fleets, the advisory is a timely reminder that endpoint security does not end at the desktop. A properly managed Windows environment can still be weakened by an unmanaged mobile device used to access or support critical systems.

---

Overview of the Johnson Controls XAAP Android Vulnerability​

The core problem is straightforward: affected versions of Johnson Controls XAAP Android store application data locally without adequate encryption. If an attacker obtains access to that data, the contents may be readable as cleartext rather than requiring a cryptographic key to decrypt.
That is the defining concern behind CWE-312. A product may have authentication, transport encryption, and server-side controls, yet still create an unnecessary exposure if sensitive material ends up on local storage in a directly recoverable form.
The affected product range is concise:

• Product: Johnson Controls XAAP Android
• Affected versions: Earlier than 1.53
• Fixed version: 1.53 or later
• Vulnerability identifier: CVE-2026-34490
• Weakness category: CWE-312
• Primary impact: Confidentiality exposure
• Remote exploitation: Not applicable
• Known public exploitation: None reported

The practical attack requirements are more restrictive than those of a typical network-facing mobile vulnerability. An attacker needs physical access to the device, or needs to compromise the device by some other means before retrieving the locally stored application data. The advisory also notes that exploitation requires local device access and does not require network connectivity.
This means the flaw should not be interpreted as a remotely reachable takeover of XAAP Android. It is instead a local confidentiality weakness whose impact depends heavily on how the device is secured, who can physically access it, whether it has been rooted or otherwise compromised, and what sensitive data the app retains.

Why a Low CVSS Score Does Not Mean “Ignore It”​

The vulnerability carries a CVSS 3.1 base score of 3.3, rated Low, alongside a CVSS 4.0 score of 4.8, rated Medium. The difference reflects the evolution of CVSS scoring rather than a contradiction in the technical description.
Under CVSS 3.1, the attack requires:

• Local access
• Low attack complexity
• Low privileges
• No user interaction
• No impact on integrity
• No impact on availability
• Low confidentiality impact

The CVSS 4.0 assessment similarly identifies local access, low privileges, and a limited confidentiality consequence, but the newer model represents the scenario differently enough to place it in the Medium severity range.
Neither score should be used in isolation as a patching decision. In enterprise environments, especially those connected to building, fire, manufacturing, facilities, or operational workflows, risk is shaped by context.
A low-to-medium technical severity can become meaningful when the affected application is deployed on:

• Shared field-service tablets
• Devices left in vehicles or equipment rooms
• Rugged Android handhelds used across multiple shifts
• Personally assigned phones enrolled with limited controls
• Tablets carrying cached job or building-system information
• Devices with weak lock-screen protections
• Devices that are no longer receiving Android security updates
• Devices used by contractors or temporary personnel

A CVSS score measures a vulnerability’s technical properties. It does not automatically measure the value of the data held by the application, the number of exposed endpoints, the resilience of the organization’s mobile-device program, or the operational damage that could follow a local information disclosure.

---

What Cleartext Storage Means in an Android App​

Cleartext storage does not necessarily mean that a file is displayed openly on a device screen. It means that sensitive information is stored without an encryption layer that meaningfully protects it from an attacker who can access the underlying file, database, cache, backup, or application storage area.
Data may be stored in forms such as:

• SQLite databases
• JSON or XML configuration files
• Application preference files
• Downloaded reports
• Log files
• Cached API responses
• Image attachments and documents
• Exported files
• Temporary files
• Crash reports
• Offline work queues
• Tokens or session artifacts

Even when a file format is not immediately readable, encoding is not encryption. Base64 text, compressed archives, serialized objects, and proprietary file extensions can all be recoverable if an attacker gains access to the device filesystem or to an unprotected application backup.
The specific data categories involved in CVE-2026-34490 have not been publicly detailed in the supplied advisory. That is an important limitation. Organizations should avoid assuming that only insignificant cached material is affected.
Until the local storage behavior is validated internally, administrators should assess XAAP Android as if locally stored application content could include operationally useful information. The exposure may range from relatively low-value metadata to details that support reconnaissance, credential misuse, social engineering, or physical access planning.

Device Encryption Is Important, but It Is Not the Entire Fix​

Modern Android devices commonly provide encryption at rest through full-disk or file-based encryption. A properly configured device lock, supported hardware, a current operating system, and verified boot protections materially reduce the chance that an attacker can extract data from a lost or stolen device.
However, operating-system encryption does not remove the application-level problem in every threat scenario.
If a device is unlocked, rooted, compromised through a separate vulnerability, or accessed through elevated debugging or forensic techniques, the operating system may already have decrypted the storage volume. At that point, an app that stores sensitive records in plaintext creates a more direct path to readable data.
This is why application-level protection and device-level protection should be viewed as complementary:

• Device encryption protects storage when the device is powered down or locked under the right conditions.
• Screen-lock controls restrict casual or opportunistic access.
• Verified boot and anti-tampering controls reduce the chance of persistent OS compromise.
• Mobile Device Management enforces policy and supports response actions.
• Application updates correct insecure data-handling behavior.
• App-level encryption or secure key storage reduces exposure even if an attacker reaches an app’s local files.

The version 1.53 update is therefore the primary remediation. Device hardening helps reduce the likelihood and impact of an attempted attack, but it is not a substitute for installing the vendor fix.

---

A Local Attack Can Still Matter in Critical Manufacturing Environments​

Johnson Controls XAAP Android is associated with an environment identified under the Critical Manufacturing sector, with deployments described as worldwide. That context raises the importance of confidentiality even when a vulnerability does not disrupt equipment or enable remote command execution.
In operational technology and facilities environments, attackers often benefit from information long before they attempt to change a setting or interrupt a process. Local application records may expose patterns that help a malicious actor understand:

• Building or site locations
• Device names and asset identifiers
• Workflow sequences
• Maintenance or inspection history
• Alarm or event terminology
• User roles
• Contact names
• Service schedules
• Network-related metadata
• Operational relationships between systems

Not all of this information will necessarily be present in XAAP Android. The point is that sensitive operational apps can become sources of context. Context allows an attacker to target a later intrusion more effectively.
For example, a stolen device with readable application files may not provide direct credentials. Yet it could help an attacker write a convincing phishing message, impersonate a technician, identify a facility process, or select a high-value target for a separate attack.
This is a common blind spot in vulnerability prioritization. Organizations may focus exclusively on flaws that promise code execution or remote access while overlooking data exposures that make those more severe attacks easier to carry out.

---

The Real Risk Depends on the Mobile Endpoint​

The advisory’s conditions make endpoint posture central to risk assessment. A device running XAAP Android below version 1.53 is not equally exposed in every deployment.

Higher-Risk Conditions​

The following conditions increase the practical concern around CVE-2026-34490:

• The device is shared among multiple employees or contractors.
• It is routinely transported between sites.
• It is stored in an accessible vehicle, cabinet, workshop, or field location.
• It uses a weak PIN, swipe-only lock, or no enforced lock timeout.
• Android security patches are outdated.
• The device bootloader is unlocked.
• The device has been rooted or modified.
• USB debugging is enabled without a compelling operational need.
• The device permits unknown-source application installs.
• Application data backups are not properly controlled.
• The device is not enrolled in an MDM or Unified Endpoint Management platform.
• Remote wipe is unavailable or untested.
• The organization cannot identify the installed XAAP Android version.
• A departing employee, contractor, or third party retains access to the device.

Lower-Risk Conditions​

Risk is reduced when the Android endpoint is managed as a business-critical asset rather than an informal accessory:

• XAAP Android is updated to version 1.53 or later.
• Full device encryption is active.
• A strong PIN or password is enforced.
• Biometric unlock is paired with an appropriately secure fallback credential.
• The device receives current Android security updates.
• Bootloader unlocking and rooting are prohibited.
• MDM enforces compliance before corporate access is granted.
• Remote wipe and device-location capabilities are enabled where appropriate.
• USB debugging and developer options are disabled.
• App deployment is controlled through managed Google Play or an equivalent enterprise channel.
• Device ownership, custody, and return procedures are documented.

The difference is significant. In a hardened fleet, an attacker may still need to defeat multiple layers before accessing application data. In a poorly managed fleet, physical possession of the device may be enough to turn a local storage flaw into a meaningful disclosure event.

---

Immediate Actions for IT and Security Teams​

Organizations should approach this as a targeted mobile application remediation exercise. The central objective is simple: identify every affected XAAP Android installation and ensure that it reaches version 1.53 or later.

1. Establish the Scope of XAAP Android Use​

Start with inventory. Do not assume that procurement records or app-store analytics accurately represent every deployed device.
Identify:

• Corporate-owned Android phones and tablets
• Ruggedized field-service devices
• Shared maintenance tablets
• Contractor-managed devices authorized to use XAAP Android
• Personally owned devices under a BYOD policy
• Devices used offline or outside normal management coverage
• Devices that are stored at remote facilities

If an MDM platform is in place, use application inventory reports to identify installed versions. Where MDM visibility is incomplete, work with operations teams, site managers, and service groups to verify local installations.

2. Update XAAP Android to Version 1.53 or Later​

The vendor’s remediation is clear: install XAAP Android version 1.53 or a later release.
A practical rollout sequence should include:

1. Confirm the current version deployed on each managed device.
2. Validate that the updated application is available through the approved distribution channel.
3. Test the update on representative devices and workflows.
4. Deploy broadly through managed app controls where possible.
5. Require update completion within a defined compliance window.
6. Block application access on devices remaining below version 1.53 if the operational model permits it.
7. Reconcile the final device list against the initial inventory.

For business-critical applications, test before rollout, but avoid allowing testing to become an indefinite reason to defer the fix. This vulnerability is not likely to require emergency overnight patching in every organization, yet it warrants a prompt and auditable upgrade cycle.

3. Confirm Android Encryption and Screen-Lock Policy​

The vendor also recommends ensuring that Android operating systems are current, device encryption is enabled, and screen-lock controls are in place.
For managed fleets, policy should require:

• Encryption at rest
• A strong PIN or password
• Automatic lock after a short inactivity period
• Biometric authentication only with a secure fallback credential
• Protection against excessive failed unlock attempts
• Current Android security patch levels
• Prohibition of device rooting and bootloader unlocking

A simple policy statement is not enough. Administrators should use compliance reporting to verify actual configuration status. A device listed as “managed” but running an outdated OS, lacking encryption, or using a weak lock is not adequately protected.

4. Use MDM or Unified Endpoint Management Controls​

A Mobile Device Management platform is one of the most useful controls for mitigating this class of vulnerability. It cannot rewrite an insecure application’s storage design, but it can reduce exposure and improve response capability.
Core MDM controls should include:

• Managed application deployment and version enforcement
• Device encryption requirements
• Minimum supported Android version policies
• Mandatory screen-lock requirements
• Root and bootloader-unlock detection
• Remote lock and remote wipe capabilities
• Application allowlisting
• Restrictions on sideloaded applications
• Restrictions on USB debugging
• Compliance-based access controls
• Asset inventory and ownership records

For environments that use Microsoft Intune alongside Windows endpoints, this work should sit within the broader endpoint-management strategy. Windows and Android compliance reporting should be reviewed together, especially when mobile apps access shared identity systems, ticketing platforms, cloud storage, or administrative workflows.

5. Review Lost and Stolen Device Procedures​

Because CVE-2026-34490 requires local access, the organization’s lost-device process is directly relevant.
A mature procedure should cover:

• Immediate reporting requirements
• A 24/7 contact path for field personnel
• Rapid remote lock or wipe authorization
• Revocation of associated sessions and tokens where applicable
• Review of the device’s last compliance state
• Documentation of data categories accessible through installed apps
• Escalation criteria for potential operational or privacy impact
• Confirmation that replacement devices receive the patched app version

The procedure should be tested. A remote wipe policy that has never been validated is an assumption, not a control.

---

What Windows Administrators Should Take From This Advisory​

This may appear to be an Android-only application issue, but the operational lesson applies directly to Windows-focused IT teams. Modern enterprise security is built around identity, endpoint posture, application data, and management visibility, not only around the operating system of a single device.
A Windows administrator may be responsible for:

• Microsoft Entra ID access policies
• Microsoft Intune compliance rules
• Conditional Access
• Windows 11 endpoint management
• Shared file services
• VPN configuration
• Help desk support processes
• Security incident response workflows

Each of those domains can influence the impact of a mobile-device vulnerability.

Conditional Access and Device Trust​

If XAAP Android users also access Microsoft 365, internal web apps, cloud storage, support portals, or remote resources, conditional access rules should distinguish between compliant and non-compliant devices.
A device that fails encryption, OS version, screen-lock, root detection, or app-version requirements should not retain the same access as a fully managed endpoint. This is especially important where Android devices can access email, shared documents, service tickets, or identity-protected portals that provide additional operational context.

Windows-Based Support Workstations​

The local nature of this flaw also highlights a broader issue: application data may move between the Android device and a Windows PC through USB transfers, backups, diagnostics, screenshots, file exports, or support workflows.
Organizations should review whether XAAP-related data can be copied to:

• Unmanaged Windows laptops
• Shared network folders
• Consumer cloud-storage services
• USB drives
• Local help desk systems
• Email attachments
• Chat applications
• Screenshot repositories

The patched Android app reduces risk on the device itself. Good data governance prevents that same information from quietly reappearing in less controlled locations.

---

Strengths in the Vendor Guidance​

The remediation guidance for this vulnerability is notable for being practical and layered. It does not rely on a single recommendation.
The strongest aspect is the clear fixed version: XAAP Android 1.53 or later. Clear version-based remediation makes it easier for administrators to automate detection, define compliance rules, and verify completion.
The additional recommendations are also appropriate for a local storage issue:

• Restrict physical access to devices.
• Keep Android operating systems current.
• Enable encryption and screen-lock protections.
• Use MDM to enforce policy.
• Avoid rooted or jailbroken devices in production.

This is a sensible defense-in-depth model. It recognizes that application flaws and endpoint weaknesses can combine. A properly patched app is the priority, but secure hardware configuration and lifecycle management reduce the chances that attackers can exploit a local weakness before patching is complete.
The advisory also avoids exaggerating the attack surface. It explicitly distinguishes this from a remote exploit and notes that no known public exploitation targeting the vulnerability has been reported. That level of precision helps organizations avoid unnecessary panic while still taking the update seriously.

---

Risks and Limitations That Remain​

There are, however, several practical limitations that security teams should keep in mind.

The Exact Data at Risk Is Not Publicly Defined​

The advisory establishes that application data could be stored in cleartext, but it does not publicly enumerate the precise fields, files, records, or tokens involved. This prevents organizations from calculating the full business impact solely from the advisory.
Security teams should therefore perform a controlled internal review of the application’s storage footprint where their policy and vendor agreements permit it. The goal is not to reverse-engineer the product recklessly, but to understand whether previous installations may have left behind sensitive records and whether an update cleans, migrates, or protects existing local data.

Updating the App May Not Remove Historical Files Automatically​

A common operational assumption is that installing a patched application immediately eliminates all traces of prior insecure storage. That may not always be true.
Depending on application behavior, legacy caches, exports, logs, databases, backups, screenshots, or files copied outside the app sandbox might remain on a device after the update. Organizations should seek vendor clarification or validate through testing whether version 1.53 remediates only future storage behavior or also addresses already-created local content.
Where a device is considered higher risk, a more conservative process may include application data clearing, secure re-enrollment, or device replacement after confirming the operational consequences.

MDM Coverage Can Be Uneven​

MDM is a powerful mitigation, but it only works for devices that are actually enrolled, reporting, and governed by enforceable policies. Field deployments often include exceptions: older hardware, contractor-owned equipment, offline devices, temporary tablets, and locations with inconsistent connectivity.
These exceptions should not become invisible populations. A vulnerability affecting locally stored data is particularly relevant to the devices that are least visible to centralized administration.

---

A Practical Remediation Checklist​

Use the following checklist to close out the XAAP Android issue in a disciplined way:

• [ ] Inventory all devices with XAAP Android installed.
• [ ] Identify every installation below version 1.53.
• [ ] Upgrade all affected devices to XAAP Android 1.53 or later.
• [ ] Confirm the successful version number after deployment.
• [ ] Identify unmanaged, BYOD, contractor, and offline devices.
• [ ] Enforce Android encryption and strong screen-lock requirements.
• [ ] Confirm supported Android OS versions and current security patches.
• [ ] Detect and block rooted, jailbroken, or bootloader-unlocked devices.
• [ ] Disable unnecessary USB debugging and developer options.
• [ ] Enforce managed app deployment where feasible.
• [ ] Validate remote lock and wipe procedures.
• [ ] Review whether legacy data, exports, caches, or backups require cleanup.
• [ ] Apply conditional access restrictions to non-compliant mobile devices.
• [ ] Document remediation status, exceptions, and risk acceptance decisions.
• [ ] Monitor for vendor updates or revised guidance.

---

Conclusion​

CVE-2026-34490 is a contained but meaningful Android application security issue. It does not expose Johnson Controls XAAP Android to unauthenticated internet attack, and it is not known to be under public exploitation. Its risk comes from a more familiar endpoint-security reality: if a device is lost, stolen, poorly protected, rooted, or compromised through another weakness, locally stored application data may be easier to recover than it should be.
The essential response is to update every affected installation to XAAP Android version 1.53 or later. That action should be paired with strong Android encryption, enforced lock-screen controls, MDM-based compliance, root prevention, and a tested lost-device response process.
For organizations operating across Windows and Android, the broader lesson is clear. Sensitive operational data can reside on any endpoint, and security posture must follow the data wherever it goes. A patched application, a managed mobile fleet, and consistent identity-based access controls together provide a far stronger defense than any one of those measures alone.

---

References​

1. Primary source: CISA
   Published: 2026-07-23T12:00:00+00:00
   
   Loading…

   www.cisa.gov
2. Related coverage: johnsoncontrols.com
   
   Loading…

   www.johnsoncontrols.com