I recently upgraded from Bahmni-Lite 1.0.0 to 1.0.2 to address CVE-2026-15477.
Since the upgrade, I’m running into two issues related to special character handling:
1. Form Conditions get HTML-encoded
In Form Builder, when I save a Form Condition containing special characters such as && or >, they get HTML-encoded once saved to the form’s JSON file.
e.g. && becomes &&, and > becomes >.
This breaks the form when you’re adding it to a patient in the clinical module.
2. Login failure with & in password
After the upgrade, I was also unable to log into Bahmni with an account whose password contains an & character.
Both issues appeared only after the 1.0.2 upgrade, so I suspect they’re a side effect of the XSS/input-sanitization hardening introduced with the fix.
Has anyone else run into this?
Is there a known workaround or mitigation?
@thomasrod Thanks for reporting this — both issues are known side effects of the OpenMRS security hardening (server-side HTML encoding of request payloads) that was introduced with the security patch.
1. Form Conditions getting HTML-encoded
This is tracked across two Jira tickets:
BAH-4360 — Form event scripts (onFormSave, onValueChanged) in the old UI - Fixed. The fix stores form events as base64-encoded strings.
Workaround: Open each affected form in Form Builder, go to the form event editor, and re-save/republish. This triggers the migration to the new encoding (look for formDefVersion:2 in the JSON).
BAH-4727 — Form metadata in the new React form2-controls - Fixed. Ensure your form2-controls dependency is up to date.
2. Login failure with & in password
There isn’t a specific ticket for this yet, but it’s very likely the same root cause — the & in the password is being HTML-encoded to & before authentication. As a temporary workaround, change the affected user’s password to one without HTML-special characters (&, <, >, ", ').We will create a bug card for this to work on.
Hope this helps! Let me know if you need more detail on any of the workarounds.