CVE-2026-12342 Readme

Which IIQ version are you inquiring about?

8.4p2

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.

Thanks for feedback!!

@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.

Anything in the build\extract path doesn’t need to be updated since that’s extracted from the SSB build correct?

@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?

@MRP4ND4 Apache will hold your war file or extracted folder.. it doesn’t store any config separately, all should come via ssb build only.

well, we are also currently reviewing this and its not very straight forward as it seems.

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.

I would include at least Form, Application, Bundle, and Workflow. Application provisioning policies are Forms inside Application, and role provisioning policies are inside Bundle, and workflow forms can also be embedded in workflow XML.

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.

Thanks everyone! This made understanding the efix much easier to understand and remediate.