Skip to content
eastbaycyber

Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.

CVE-2026-118636: Apache MINA RCE Risk

CVSS · Critical
9.8
In CISA KEV
No
Published
Oct 31
Patch SLA & TriageVector: Network
24 to 48 hours

Critical CVSS (9.8) reachable over network.

Exposure:
Control:
CVSS v3.1 Blast RadiusCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Decode Vector & Sub-Scores →
CVE explainers 10 min read
Security Research Desk Source-checked
Auto-checked against the official CVE record · Human-reviewed after publishing · Updated 2026-10-31
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - CVE-2026-118636 is a critical CWE-502 flaw in Apache MINA 3.0’s JavaNativeMessageDecoder. - MINA 3.0.0 and 3.0.0-M2 are affected when the decoder accepts data from an untrusted peer. - No 3.0 fix is planned; restrict exposure and migrate to the latest Apache MINA 2.2.x release.

CVE-2026-118636 is a critical Apache MINA vulnerability involving unsafe Java deserialization in the 3.0 codec module. When JavaNativeMessageDecoder processes attacker-controlled data from an untrusted network peer, ObjectInputStream.readObject() may enable gadget-chain remote code execution.

Organizations tracking related vulnerabilities can also review our coverage of CVE-2026-90970 and CVE-2026-82041.

Summary

CVE-2026-118636 affects Apache MINA 3.0.0 and 3.0.0-M2 when an application uses the vulnerable JavaNativeMessageDecoder to process data from an untrusted peer. The decoder passes serialized frame data to Java’s ObjectInputStream.readObject() without applying a class filter.

If the target application contains classes capable of forming a gadget chain, crafted serialized input may result in remote code execution. The attack requires the vulnerable decoder to be active and reachable, so not every Apache MINA installation has the same exposure.

Field Value
CVE ID CVE-2026-118636
CVSS 9.8 Critical
CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack vector Network
Authentication / privileges required None (PR:N)
User interaction None (UI:N)
Vulnerability CWE-502, deserialization of untrusted data
Affected component Apache MINA 3.0 codec module, JavaNativeMessageDecoder
Affected versions Apache MINA 3.0.0 and 3.0.0-M2
Patch available No fix planned for the inactive 3.0 branch
Recommended target Latest available Apache MINA 2.2.x release
CISA KEV Not listed

Apache’s disclosure states that the 3.0.0 branch is inactive and that the project does not plan to release a fixing version for that branch. Migration, rather than a conventional point upgrade, is therefore the primary remediation.

Analyst’s Take: First determine whether JavaNativeMessageDecoder is active on a listener reachable by an untrusted peer. If it is, prioritize containment and migration. If the decoder is unused, the reported attack path may not apply, but dependency and configuration review are still necessary.

AnalystImpact · assess the risk

Root Cause

The vulnerable code path uses Java native deserialization on bytes received in a MINA frame:

ObjectInputStream.readObject()

Java native deserialization can instantiate classes and invoke deserialization-related behavior before the application safely validates the object’s type. If suitable gadget classes are present in the application classpath, crafted input may trigger unintended method execution during deserialization.

The reported defect is the absence of an appropriate class filter around this operation. The decoder processes network input as a serialized Java object stream without enforcing an adequate trust boundary.

The issue is not automatically exploitable in every MINA 3.0 deployment. Exploitation requires:

  1. Apache MINA 3.0.0 or 3.0.0-M2.
  2. The affected codec module.
  3. JavaNativeMessageDecoder in the active filter chain.
  4. A listener reachable by an untrusted peer.
  5. A usable gadget chain in the target classpath.

Technical Notes

The behavior described by the advisory is equivalent to:

ObjectInputStream input =
    new ObjectInputStream(frameInputStream);

Object object = input.readObject();
// No ObjectInputFilter is applied before deserialization.

A secure redesign should avoid Java native serialization for untrusted protocol data. If compatibility requirements make deserialization unavoidable temporarily, use an explicit allowlist-based ObjectInputFilter, validate protocol framing and message types, and restrict network access.

Filtering is defense in depth, not a substitute for migrating away from the affected branch.

Who’s Exposed

The specifically affected versions are Apache MINA 3.0.0 and 3.0.0-M2. The vulnerable functionality is in the MINA 3.0 codec module, specifically JavaNativeMessageDecoder.

Organizations may be exposed when an application includes the affected module and configures the decoder to process data from an untrusted peer. Potentially affected deployments include:

  • Public-facing protocol services.
  • Externally reachable administrative endpoints.
  • Partner integrations.
  • Internal services reachable from compromised hosts.
  • Services accepting serialized Java objects from unauthenticated clients.
Deployment condition Assessment
MINA 3.0.0 or 3.0.0-M2 is present, but the decoder is unused Reported attack path is not established; inventory and code review are still required
Decoder processes only trusted, authenticated peers Reduced exposure, but not risk-free
Decoder is reachable by unauthenticated network clients High-priority exposure
Application accepts arbitrary serialized objects from the internet Critical operational concern
MINA 2.2.x deployment Not identified by the supplied advisory as affected; verify the exact dependency and configuration

The available research does not provide a complete transitive dependency list or universal product scanner. Search build manifests, dependency outputs, container layers, application bundles, and deployed artifacts. MINA may be inherited through a framework or internal platform component.

Severity Breakdown

CVE-2026-118636 has a CVSS 3.1 score of 9.8, classified as Critical:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Metric Value Operational meaning
Attack Vector Network (AV:N) The attacker can send input over the network
Attack Complexity Low (AC:L) No unusual conditions are required beyond reaching the service
Privileges Required None (PR:N) Authentication is not required
User Interaction None (UI:N) No victim action is required
Scope Unchanged (S:U) Impact remains within the vulnerable security authority
Confidentiality High (C:H) Successful exploitation may expose sensitive data
Integrity High (I:H) Successful exploitation may alter application or host data
Availability High (A:H) Successful exploitation may disrupt service or host operation

The score describes potential impact under the stated conditions. It does not prove that every deployment is reachable or that every classpath contains a usable gadget chain. However, the absence of a public exploit should not be treated as a compensating control.

Exploitation Status

The supplied primary sources do not confirm active exploitation in the wild. CVE-2026-118636 is also not listed in the CISA Known Exploited Vulnerabilities catalog.

No public proof-of-concept repository or exploit code was identified in the supplied sources. Exploitability may vary because Java deserialization attacks depend on the target’s application classpath and available gadget chains.

Question Current assessment
Is active exploitation confirmed? No confirmation in the supplied sources
Is the CVE in CISA KEV? No
Is a public PoC identified? No public PoC identified in the supplied sources
Is exploitation technically possible? Potentially, if an untrusted peer reaches the decoder and a usable gadget chain is available
Should defenders wait for exploitation evidence? No; the 3.0 branch has no planned fix

A KEV-negative result means only that no CISA catalog entry was identified at the time of assessment. It does not establish that the service is safe or that private exploitation is absent.

Technical Notes

Monitor for unexpected child processes, network services, and Java process execution. On Linux, a basic process-monitoring query can identify suspicious Java descendants:

sudo ausearch -m EXECVE -ts recent \
  | grep -Ei 'java|/bin/sh|/bin/bash|curl|wget|nc|ncat|python|perl'

For Elastic environments, an example triage query is:

process.parent.name : ("java" or "java.exe") and
process.name : ("sh" or "bash" or "cmd.exe" or "powershell.exe" or
                "curl" or "wget" or "nc" or "ncat" or "python" or "perl")

This is not a CVE-specific signature and should be tuned to normal application behavior. Also review MINA listener logs for:

  • Decoder exceptions.
  • Abrupt disconnects.
  • Unusually large frames.
  • Connections followed by unexpected process execution.
  • Unexpected outbound connections from the Java process.

The supplied material does not provide a validated byte-level signature, so defenders should not rely on a fabricated payload pattern.

Affiliate Security Tools

Organizations reviewing exposed Java services may also benefit from endpoint and credential-protection tools. For example, Get Bitdefender → can support malware detection and response workflows, while Try 1Password → may help teams enforce stronger credential practices during incident response and migration projects. These tools do not patch CVE-2026-118636 and should supplement—not replace—dependency remediation and network containment.

Sources

The primary Apache security disclosure is the most important reference for the vulnerability description, affected versions, CVSS score, remediation direction, and inactive-branch status:

The CVE record provides the canonical identifier and record-level metadata:

The Apache mailing-list reference is available here. The retrieved page rendered the Pony Mail application shell rather than the message body, so it should be used alongside the primary disclosure rather than treated as an independently verified technical source:

Project information and release verification should be obtained from the Apache MINA project:

The supplied CISA KEV check reported on_kev: false. This means no CISA KEV entry or associated exploitation metadata was identified at the time of assessment. It does not reduce the need to migrate exposed MINA 3.0 deployments.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

ResponderRunbook · act now

Detection Guidance

Start with asset and dependency inventory. Locate Apache MINA 3.0.0 and 3.0.0-M2 in Maven, Gradle, container layers, application bundles, and running Java processes.

Dependency scanners can identify the library but generally cannot determine whether JavaNativeMessageDecoder is active. Application source, configuration, and runtime inspection are necessary.

Next, map the decoder to network exposure. Identify the listener address, port, protocol, load balancer, firewall policy, and authentication controls. A service bound only to a controlled loopback interface has a different risk profile from an internet-facing listener, although internal reachability should not automatically be considered trusted.

Technical Notes

Search common Java build files:

grep -RInE 'org\.apache\.mina|mina-core|mina.*codec|3\.0\.0(-M2)?' \
  pom.xml build.gradle settings.gradle gradle.lockfile 2>/dev/null

mvn dependency:tree | grep -i mina
./gradlew dependencies | grep -i mina

Search application code and configuration:

grep -RInE 'JavaNativeMessageDecoder|ObjectInputStream|readObject' \
  src/ config/ 2>/dev/null

Inspect listeners and deployed artifacts:

sudo ss -lntup

sudo find /opt /srv /app -type f \
  \( -iname '*mina*.jar' -o -iname '*.war' -o -iname '*.ear' \) \
  -print 2>/dev/null

jar tf /path/to/application.jar | grep -Ei 'mina|JavaNativeMessageDecoder'

Correlate client connections to the service with application and host telemetry:

source.ip: * AND destination.port: <MINA_LISTENER_PORT>
AND event.action: (network_connection OR process_start)

Investigate sequences in which an external source connects to the MINA listener and the Java process subsequently launches a shell, scripting interpreter, downloader, or unexpected executable.

If compromise is suspected, preserve Java process state, relevant heap or crash artifacts where safe, application logs, authentication records, network flow data, and host command-execution telemetry. Avoid restarting or redeploying before collecting evidence unless containment requires immediate shutdown.

Remediation Steps

The primary remediation is to migrate affected applications from Apache MINA 3.0.x to the latest available Apache MINA 2.2.x release. The supplied advisory does not identify a specific fixed 2.2.x version, so verify the current Apache release information before deployment.

Do not treat another Apache MINA 3.0.x build as a fix. Apache states that the branch is inactive and that no fix is planned for it.

Before migration:

  1. Identify protocol compatibility requirements.
  2. Review transitive dependencies and API changes.
  3. Test application and integration behavior.
  4. Remove JavaNativeMessageDecoder if native serialization is unnecessary.
  5. Replace Java native serialization with a schema-based format designed for untrusted input where possible.

Until migration is complete:

  • Restrict access to the affected listener.
  • Remove direct internet exposure.
  • Enforce network allowlists.
  • Require authenticated and authorized peers where supported.
  • Disable the decoder or endpoint if operationally possible.
  • Apply host egress controls.
  • Monitor for unexpected Java child processes.

These controls reduce attack surface but should be tracked as temporary mitigations rather than permanent remediation.

Technical Notes

A Maven dependency should be updated to the latest verified 2.2.x release selected after checking Apache’s current release information:

<dependency>
  <groupId>org.apache.mina</groupId>
  <artifactId>mina-core</artifactId>
  <version>2.2.x-VERIFIED-RELEASE</version>
</dependency>

Replace the placeholder with the actual verified release before deployment. Do not deploy the literal placeholder.

Then rebuild and verify the dependency graph:

mvn -U clean verify
mvn dependency:tree -Dincludes=org.apache.mina

For Gradle:

dependencies {
    implementation("org.apache.mina:mina-core:2.2.x-VERIFIED-RELEASE")
}
./gradlew clean test dependencies --configuration runtimeClasspath \
  | grep -i mina

If an immediate code-level workaround is required, remove the vulnerable decoder from the filter chain or stop the listener that feeds it. The exact API depends on the application, so administrators should not copy an unverified filter-chain mutation into production.

A generic operational sequence is:

1. Disable the listener or route it away from untrusted networks.
2. Remove JavaNativeMessageDecoder from the active filter chain.
3. Redeploy with a non-native-serialization decoder.
4. Confirm that the listener accepts only the intended protocol and peer set.
5. Validate with an authorized integration test.
6. Review process and network telemetry after deployment.

If the service cannot be migrated promptly, isolate it on a restricted network, require mutually authorized peers where supported, apply host egress controls, and monitor for unexpected Java child processes.

For additional vulnerability context, see the CVE-2026-105207 analysis and the July 31 security digest.

Last verified: 2026-10-31

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.