Security advisories

Summary

The ironweb SDK encrypts device and signing private keys before storing them in the browser's local storage. A single AES-GCM initialization vector (IV) was used to encrypt both the device private key and the signing private key under the same symmetric key.

Impact

An attacker with read access to a user's local storage (e.g. via XSS or physical access to the browser) could XOR the two ciphertexts to recover the XOR of the device private key and the signing private key. The integrity properties of AES-GCM are also weakened under IV reuse, potentially allowing ciphertext forgery.

Exploitation requires access to the encrypted keys in local storage. The keys encrypted in local storage are an additional layer of defense. Note that these keys are also ephemeral by nature and are often rotated on a per session basis.

NOTE: We assigned this a low severity because the IV was only reused to encrypt two randomly generated strings of bytes (two private keys), decreasing the possibility of recovering pieces of one or the other of the plaintext strings from the XOR.

Mitigation

Upgrade to ironweb 4.2.51 or later. The fix generates a separate random IV for each key encryption and transparently migrates existing locally-stored keys on the next SDK initialization. No user action is required beyond upgrading the SDK version.

Acknowledgements

This issue was reported by Swyam Sharma on 2/10/2026.

Summary

A CORS misconfiguration was detected on IronCore's primary website.

Affected Systems

• ironcorelabs.com

Mitigation

The endpoint in question was part of the web hosting platform and has since been disabled.

Acknowledgements

Thanks to Shubham Garg for this report.

Summary

After logging out of the Admin Console, anyone retaining the deleted login cookie could still use the system.

Affected Systems

• admin.ironcorelabs.com

Mitigation

None. This issue was resolved shortly after receipt. Login cookies no longer work after a logout event.

Acknowledgements

Thanks to Jayesh Patel for this report on 8/4/18 and to Sumit Jain who reported it a short time later.

Summary

Certain ironcorelabs.com subdomains were lacking SPF records.

Acknowledgements

Thanks to Shivam Lohani for the report.

Summary

The randomness of some operations was reduced after a regression was introduced in recrypt-rs 0.8.0. Affected 256-bit operations were:

• CryptoOps::gen_plaintext
• CryptoOps::transform
• KeyGenOps::generate_transform_key

480-bit operations were not affected.

Affected Systems

• Primary:
• recrypt-rs 0.8.0 - 0.8.3
• Secondary (due to dependency on vulnerable recrypt-rs):
• recrypt-wasm-binding 0.5.3
• recrypt-node-binding 0.5.0 - 0.6.0
• ironnode 0.7.0 - 0.7.2
• ironhide 0.6.0 - 0.6.1
• ironoxide 0.9.0 - 0.12.0
• ironoxide-swig-bindings 0.4.3 - 0.6.0
• ironoxide-scala 0.3.1 - 0.5.0

All impacted versions have been removed from distribution and patch version bumps with the fix have been released.

Mitigation

We recommend that all users upgrade as soon as possible. Furthermore, we recommend that any keys generated while using a vulnerable library be regenerated if they're used for production purposes. Please note that all encryption operations generate per-object keys as part of encryption, so we recommend that all documents encrypted using these versions of the SDKs be re-encrypted using new document IDs. Groups created using these versions of the SDKs should be re-created, and any data encrypted to the old groups should be encrypted to the new ones.

Acknowledgements

This issue was found by our team during internal testing.*