dbcve.org
UimajApplication · Apache

CVE-2023-39913

HIGH · 8.8 CVSS v3.1 Published 2023-11-08
Fix available
A fix is available. Upgrade to 3.5.0 or later.
See remediation →
94/100
Remediation priority · Urgent
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Deserialization of Untrusted Data, Improper Input Validation vulnerability in Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK.This issue affects Apache UIMA Java SDK: before 3.5.0. Users are recommended to upgrade to version 3.5.0, which fixes the issue. There are several locations in the code where serialized Java objects are deserialized without verifying the data. This affects in particular: * the deserialization of a Java-serialized CAS, but also other binary CAS formats that include TSI information using the CasIOUtils class; * the CAS Editor Eclipse plugin which uses the the CasIOUtils class to load data; * the deserialization of a Java-serialized CAS of the Vinci Analysis Engine service which can receive using Java-serialized CAS objects over network connections; * the CasAnnotationViewerApplet and the CasTreeViewerApplet; * the checkpointing feature of the CPE module. Note that the UIMA framework by default does not start any remotely accessible services (i.e. Vinci) that would be vulnerable to this issue. A user or developer would need to make an active choice to start such a service. However, users or developers may use the CasIOUtils in their own applications and services to parse serialized CAS data. They are affected by this issue unless they ensure that the data passed to CasIOUtils is not a serialized Java object. When using Vinci or using CasIOUtils in own services/applications, the unrestricted deserialization of Java-serialized CAS files may allow arbitrary (remote) code execution. As a remedy, it is possible to set up a global or context-specific ObjectInputFilter (cf. https://openjdk.org/jeps/290  and  https://openjdk.org/jeps/415 ) if running UIMA on a Java version that supports it. Note that Java 1.8 does not support the ObjectInputFilter, so there is no remedy when running on this out-of-support platform. An upgrade to a recent Java version is strongly recommended if you need to secure an UIMA version that is affected by this issue. To mitigate the issue on a Java 9+ platform, you can configure a filter pattern through the "jdk.serialFilter" system property using a semicolon as a separator: To allow deserializing Java-serialized binary CASes, add the classes: * org.apache.uima.cas.impl.CASCompleteSerializer * org.apache.uima.cas.impl.CASMgrSerializer * org.apache.uima.cas.impl.CASSerializer * java.lang.String To allow deserializing CPE Checkpoint data, add the following classes (and any custom classes your application uses to store its checkpoints): * org.apache.uima.collection.impl.cpm.CheckpointData * org.apache.uima.util.ProcessTrace * org.apache.uima.util.impl.ProcessTrace_impl * org.apache.uima.collection.base_cpm.SynchPoint Make sure to use "!*" as the final component to the filter pattern to disallow deserialization of any classes not listed in the pattern. Apache UIMA 3.5.0 uses tightly scoped ObjectInputFilters when reading Java-serialized data depending on the type of data being expected. Configuring a global filter is not necessary with this version.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Apache UIMA Java SDK versions before 3.5.0 contain insecure deserialization vulnerabilities where Java-serialized objects are deserialized without input validation. This affects CasIOUtils, Vinci services, Eclipse plugins, and CPE checkpointing, allowing arbitrary code execution through malicious serialized payloads.

MitigationUpgrade to Apache UIMA Java SDK 3.5.0 which implements tightly scoped ObjectInputFilters; alternatively, configure Java 9+ jdk.serialFilter system property to whitelist allowed classes.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
UimajApplication
Affected:< 3.5.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Apache UIMA Java SDK version
    Locate uima-core.jar or uima jars in your application classpath, lib directory, or Maven/Gradle dependencies (pom.xml, build.gradle). Check the filename or dependency version for the numeric version (e.g., uima-core-3.4.0.jar)
    Affected if The installed version is any release before 3.5.0 (e.g., 3.4.0, 3.3.1, 3.2.0, etc.)
  2. Determine if CasIOUtils is in use
    Search your codebase and runtime classpath for references to CasIOUtils class or the CasIOUtils.java file, which handles CAS (Common Analysis Structure) serialization/deserialization
    Affected if CasIOUtils is loaded and your application deserializes CAS data from untrusted sources using it
  3. Determine if Vinci services are enabled
    Check your application configuration, deployment descriptors, or service registration files for Vinci service configurations. Vinci is the UIMA service framework for remote analysis engine deployment
    Affected if Vinci services are enabled and accept serialized Java objects from network clients
  4. Determine if CPE checkpointing is used
    Check for CPE (Collection Processing Engine) configurations that use checkpointing. Look for CPE descriptor files or checkpoint-related settings in your UIMA pipeline
    Affected if CPE checkpointing is enabled and serializes processing state to disk that could be tampered with
  5. Check for raw ObjectInputStream deserialization
    Search your application code and UIMA-related libraries for usage of java.io.ObjectInputStream without ObjectInputFilter, particularly in UIMA component code that handles external input
    Affected if ObjectInputStream is used to deserialize Java objects from untrusted input sources without input filtering

You are affected if your Apache UIMA Java SDK version is below 3.5.0 AND you use CasIOUtils, Vinci services, CPE checkpointing, or any other mechanism that deserializes Java objects from untrusted sources without ObjectInputFilter protection.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 3.5.0 or later
Fixed in 3.5.0
Interim mitigation

Upgrade to Apache UIMA Java SDK 3.5.0 which implements tightly scoped ObjectInputFilters; alternatively, configure Java 9+ jdk.serialFilter system property to whitelist allowed classes.

Recommended fix High confidence

3.5.0

  1. 1. Identify all deployments of Apache UIMA Java SDK in your environment that are running versions before 3.5.0.
  2. 2. Plan an upgrade to version 3.5.0 for each affected deployment.
  3. 3. Obtain Apache UIMA Java SDK version 3.5.0 from the official Apache distribution repository.
  4. 4. Replace the older UIMA library JAR files with the version 3.5.0 JAR files in all affected applications and services.
  5. 5. Test your applications thoroughly after the upgrade to ensure compatibility and that the deserialization functionality works as expected.
  6. 6. If running on Java 1.8, upgrade to a newer Java version (Java 9+) as ObjectInputFilter is not available on Java 1.8.
  7. 7. Verify that no locally configured Vinci services or other vulnerable entry points remain exposed.
Caveat The description does not report breaking changes; however, as with any upgrade, conduct regression testing to verify application compatibility

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Uimaj Scoped from the published advisory
  • Consultation6.0 h
  • Implementation12.0 h
  • Testing8.0 h
  • Review / QA4.0 h
30.0 hours of engineering $5,280
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $8,448.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2023-39913 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2023-39913 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data