Share all details about your problem, including any error messages you may have received.
Hi Everyone,
I’m wanting to connect and make sure i’m understanding the efix for CVE-2026-12342. Within the README there are some additional instructions about scriplets.
Will this EFIX not actually work until those instructions are followed? It seems rather interesting to me that this would be a requirement, especially considering some env may have 100s if not 1000s of objects…
Additional Instructions in the README: Scriptlets are no longer allowed as user input and thus may not be used as Field values. Fields that use a scriptlet as the value will need to be manually converted to use an associated Script element instead.
@MRP4ND4 The eFix works right away for blocking the vulnerability — scriptlets as user input are no longer evaluated, which is the whole point of the CVE fix. Existing objects that rely on scriptlet Field values will stop working after the eFix is applied, because the platform will now reject those inline scriptlets.
Practical approach for environments with hundreds/thousands of objects:
Export your XML objects and search for patterns (or similar scriptlet syntax in Field value attributes) to identify what needs converting.
Convert each to use a child element instead of an inline value within the Field.
Prioritise by testing in lower environments first — not every Field will have a scriptlet value, so the actual count of affected objects may be smaller than the total object count.
@MRP4ND4 build\extract is the extracted/unzipped version of your project war. Once you update everything in config folder, it should auto update everywhere after the build.
and assume the same goes for apache. So just need to look into my identityiq\config folder for the objects, update those and then all is good essentially?
Hello Cody. One thing I would add before treating identityiq/config as complete: that is your SSB source, but it may not match what is currently stored in IIQ if objects were changed through the UI or imported directly.
I would export the relevant configuration objects from the running instance and scan those as a second inventory. The console export command can target specific classes, which I would prefer over exporting everything in a larger environment.
For an affected Field, the README is asking you to move the scriptlet into the nested Script element, for example:
<Field ...>
<Script>
<Source>
// existing BeanShell returning the Field value
</Source>
</Script>
</Field>
I would compare the live export with the SSB source, make the conversions in SSB, apply them to a lower environment through your normal deployment/import process, then export and re-scan to confirm nothing was missed.
I would also avoid locking into a search pattern such as value="script:" until you confirm the exact legacy syntax from the IIQSR-983 README against a known affected Field.