The 60-second summary
CERT-In issued CIVN-2026-0537 on 4 November 2026, rated High. It lists iRA 2.0 versions 26.7.3 and earlier and iRA.ev versions 26.7.2 and earlier as affected. The specified upgrades are 26.8.2 and 26.9.1 respectively. The issues concern embedded credentials, WebView handling, sensitive logging and certificate-pinning configuration.
Timeline that matters
4 November 2026
Advisory issued
CIVN-2026-0537.
2026-11-05
Reviewed
Prepared for human editorial review against the listed primary sources.
2026-11-06
Next review
Check official changes and any unresolved status questions.
What changed
The advisory provides concrete affected and fixed versions. An app upgrade and confirmation that exposed credentials can no longer be used are different verification tasks; the latter requires evidence from the responsible service owner.
Who should pay attention?
Application users and administrators
Confirm the installed product and available fixed build through an official distribution route.
Developers and service owners
Review package contents, token exposure and service-side credential lifecycle.
What the guidance clarifies
- Status and urgency
- High-severity product vulnerability advisory, not a finding of a breach in every installation. Editorial urgency: High for affected deployments.
- Evidence limits
- The advisory does not establish exploitation in a particular organisation or prove that all potentially exposed credentials have been revoked.
- Version checks
- Verify the installed product and the fixed build available for its platform. Do not infer identical availability across app stores.
- Educational use
- Educational information only, not legal advice. The implementation checklist is original PrivacyBuilt analysis; adapt it to the facts, applicable obligations and qualified specialist advice. No regulator, standards-body or vendor endorsement is implied.
Practical relevance
Why this matters for global organisations.
Discovery should connect an exposed secret to its owner, permissions and revocation path. Removing a value from a new app package does not establish whether an old credential still works or whether earlier access needs investigation.
- Track software remediation and credential invalidation separately.
- Store evidence as references or redacted values rather than reusable secrets.
10 actions to start now
- Inventory affected product installations and assign an update owner.
- Check the installed build against the advisory and the official app-store listing.
- Deploy the applicable fixed build and retain installation verification.
- For owned products, scan release packages and build outputs using authorised secrets-discovery tooling.
- Validate findings with the service owner without testing credentials against systems outside the approved scope.
- Determine permissions and exposure duration; revoke or rotate confirmed exposed credentials under an approved change plan.
- Review token handling at WebView boundaries and remove sensitive values from logs.
- Restrict access to collected packages and logs; retain redacted evidence wherever possible.
- Assess available service telemetry for misuse and document uncertainty where coverage is incomplete.
- Evaluate notification duties from the actual impact with counsel; track software and credential closure separately.
Suggested next steps
- Inventory affected product installations and assign an update owner.
- Evaluate notification duties from the actual impact with counsel; track software and credential closure separately.
- Next editorial review: 2026-11-06; recheck the official sources before publication.
Evidence worth retaining
- Installed and replacement build records.
- Redacted finding references linked to service owners and privileges.
- Revocation or rotation confirmation and deployment approvals.
- Telemetry coverage, exposure assessment and closure decisions.
Questions to take to counsel or your conformity team
These are discussion prompts, not legal advice or conclusions.
- Can a credential extracted from an older package still be used?
- Which backend permissions and records were reachable?
- Who can confirm revocation without exposing the value again?
- What evidence supports or limits conclusions about actual misuse?
Official sources
PrivacyBuilt / PrivacyBuilt is an independent educational publisher. It is not affiliated with, or endorsed by, any regulator or the European Union.
PrivacyBuilt publishes educational and technical guidance. Nothing on this site constitutes legal advice, and it should not be relied on as a legal determination for your organisation.