High Prisma CVEs in owlready2 bundled JARs (Jena 2.10.0) - guidance needed

[Ejas Ali]

Hi,

Two high Prisma vulnerabilities (CVEs) are being reported for the owlready2 package due to the following bundled JARs:

CVE-2021-39239 - /lib/python3.11/dist-packages/owlready2/pellet/jena-arq-2.10.0.jar
CVE-2021-39239 - /lib/python3.11/dist-packages/owlready2/pellet/jena-core-2.10.0.jar

We attempted to upgrade these JARs to the fixed version (4.2.0), but doing so breaks owlready2 functionality. Please advise on a recommended fix or supported alternative, and let us know if there is a planned timeline for addressing these vulnerabilities in owlready2.

Regards,
Ejas Ali

[Jiba]

Hi,

These old JARs are used to support Pellet.

If you don't need Pellet, you can just remove the JARs.

If you do need Pellet, it's more complicated... we need to manage to recompile Pellet with updated/fixed JARs, which is not an easy task : updating from version 2.10 to 4.2 is a big leap :-(

Another solution would be to delete the support for XML entity in the JARs (I think Owlready don't use them), which would prevent the vulnerability ?

Jiba

[Jiba]

After looking at Owlready2 codes, it appears that XML is not used to communicate with Pellet (NTriple files are used instead). Consequently, the vulnerability cannot occur and we don't need XML loading functionality.

I managed to disable XML loading in Jena by modifying/commenting org/apache/jena/riot/lang/LangRDFXML.java, which fix the vulnerability.

I also verified that the vulnerability does not occur within Owlready2 in Python.

Jiba

[Ejas Ali]

Hi, thank you for your reply. Disabling XML loading may not prevent the JAR from being flagged in a Prisma scan.

Has this issue been fixed in the latest version of Owlready2?

Is there a planned timeline for addressing these vulnerabilities in Owlready2?

Thank you

[Jiba]

Okay, so what could we do for preventing the JAR from being flagged in a Prisma scan? Rename the JAR ? Remove some dangerous and unused file from it ?

Jiba

[Ejas Ali]

Yes, please upgrade the JAR files and release a new version of Owlready2 that includes this fix. Specifically, the following dependencies need to be upgraded to version 4.2.0, where this CVE has been resolved:

/owlready2/pellet/jena-arq-fixed2.10.0.jar
/owlready2/pellet/jena-core-fixed2.10.0.jar

Is there a plan in place to address this issue? If so, could you please share the expected timeline?

Regards,
Ejas Ali

[Jiba]

Updating Pellet to use the latest version of Jena is beyond my skill in Java :-(

Do you know how this vulnerability is detected ? Is there some vulnerability scanner ? Since I modified the old version of Jena so as the issue is no longer present, there should be a mean to avoid the detection -- perhaps by changing the version number, since it is no longer the same version.

Jiba

[Ejas Ali]

Hi Jiba,

Thank you for the detailed investigation and for modifying the Jena JARs to disable XML loading — that's very helpful context.

Scanners typically detect vulnerabilities like this by reading the version number in the JAR manifest (MANIFEST.MF) and matching it against a known CVE database. They generally do not test whether the vulnerable code path is actually reachable. so even though you've disabled XML loading, the version number 2.10.0 still matches the CVE entry and Prisma continues to flag it.

Your suggestion of changing the version number in the JAR manifest sounds like the right approach. If the manifest version is updated to reflect that the JAR has been patched (e.g., appending -patched or bumping it above the fixed threshold), scanners would likely no longer flag it.

Could you please consider the following for the next owlready2 release:

1. Update the MANIFEST.MF version inside jena-arq-2.10.0.jar and jena-core-2.10.0.jar to reflect the patch (e.g., 2.10.0-owlready-patched or 4.2.0 since XML loading has been fully disabled).
2. Include this in a new owlready2 release so users can pick it up via a standard pip install --upgrade owlready2.

This would resolve the Prisma flagging without requiring a full Jena 4.x migration. Would this be feasible?

Thank you again for your continued support on this.

Regards,
Ejas Ali