GCVE-1988-2026-0074
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
Chronicle Wire v2026.8 Insecure Reflection Allows Unvalidated Method Invocation
Summary
Chronicle Wire's MethodReader implements message dispatch by dynamically
mapping serialized wire events to Java handler methods. During
initialization, the framework discovers public methods exposed by the
registered handler interfaces and registers those methods as callable wire
events.
When a message is processed, the event name supplied within the wire data
determines which registered handler method is selected. Method arguments
are then deserialized from the corresponding message content, and Chronicle
Wire invokes the selected method using Java Reflection.
As a result, when untrusted wire data reaches a MethodReader, externally
controlled input can determine both the handler method selected for
invocation and the arguments supplied to that method.
The dispatch surface is derived automatically from the handler's public
interface rather than from an explicit list of individually registered
operations. Public methods added to a registered handler interface can
therefore become dispatchable wire events without separate method-level
registration.
This behavior becomes security-sensitive when a handler interface contains
privileged or security-sensitive operations and its MethodReader processes
data from an untrusted source. In such deployments, methods intended for
file access, network operations, key management, maintenance,
administrative functionality, or other privileged actions may become
reachable through externally controlled event names.
Vulnerability Details
VanillaMethodReader constructs its dispatch surface from the handlers
supplied by the application:
addParsersForComponents(handler);
During initialization, Chronicle Wire enumerates the public methods
associated with the handler:
for (Method method : handlerClass.getMethods()) {
addParseletForMethod(method);
}
Eligible methods are subsequently registered for wire-event dispatch.
The method name and parameter types are used to construct the corresponding
wire key:
MethodWireKey key =
new MethodWireKey(
method.getName(),
parameterTypes);
This means the set of methods callable through the wire protocol is derived
from the public methods exposed by the registered handler interface.
When incoming wire data is processed, the supplied event name is matched
against the registered method dispatch table. The corresponding argument
values are then deserialized according to the selected method's declared
parameter types:
arguments[i] =
valueIn.object(parameterTypes[i]);
After argument deserialization, the selected Java method is invoked
reflectively:
method.invoke(target, arguments);
Consequently, externally controlled wire data participates directly in two
security-sensitive decisions: selecting which registered handler method is
executed and supplying the arguments passed to that method.
The dispatch mechanism itself does not introduce a method-level
authorization decision between event selection and invocation. The
effective security boundary is therefore determined by which interfaces are
registered with MethodReader, which public methods those interfaces expose,
and whether the application permits untrusted data to reach the reader.
Root Cause
The security issue arises from automatically deriving the externally
dispatchable method surface from public methods exposed by registered
handler interfaces.
Chronicle Wire:
-
Discovers public methods associated with registered handlers.
-
Registers eligible methods as wire-event handlers.
-
Resolves incoming event names to those methods.
-
Deserializes method parameters from the corresponding wire input.
-
Invokes the selected methods using Java Reflection.
The dispatch model does not require each callable operation to be
independently exported or registered at the method level. Consequently, the
security boundary of a MethodReader can expand when additional public
methods are introduced into an interface already used for wire dispatch.
This creates a risk in applications where the registered handler interface
contains operations that should not be reachable by the party controlling
the wire input.
The issue is particularly significant when interfaces evolve over time.
Adding a new public operation to an existing MethodReader-facing interface
can simultaneously add that operation to the wire dispatch surface without
a separate dispatch registration step.
Impact
When untrusted input reaches a MethodReader, an attacker can select among
the public operations exposed through the registered handler interface and
provide serialized arguments for the selected operation.
The resulting security impact depends on the functionality implemented by
those handlers.
Security-sensitive methods may include:
-
file access and file modification;
-
outbound network communication;
-
administrative operations;
-
key rotation or key-management operations;
-
configuration changes;
-
maintenance functionality;
-
state-changing business operations; and
-
other privileged application functionality.
If such operations are exposed through a registered handler interface,
externally controlled event names can cause those methods to be invoked
with externally supplied arguments.
The attack surface can also change as the application evolves. A public
method added to an interface already participating in MethodReader dispatch
may become a new wire operation without requiring separate registration of
that individual method.
Methods accepting broad or polymorphic argument types introduce an
additional concern. Arguments are processed through Chronicle Wire's object
deserialization mechanisms:
arguments[i] =
valueIn.object(parameterTypes[i]);
Where the declared parameter type permits serialized type information to
influence runtime object selection, externally controlled input may affect
both the *method selected for invocation* and the *runtime object
instantiated as its argument*.
The resulting vulnerability therefore combines an externally controlled
method-dispatch surface with attacker-controlled argument deserialization.
The ultimate impact depends on the operations exposed by the registered
handler and the trust boundary through which wire messages are received.
Proof of Concept
The proof of concept demonstrates that Chronicle Wire's MethodReader allows
serialized event names to select public methods exposed by a registered
handler and supplies those methods with arguments deserialized from the
corresponding wire message.
The tests exercise several handler operations to demonstrate method
selection, privileged-operation reachability, automatic expansion of the
dispatch surface, and typed argument deserialization.
Administrative Method Invocation
The registered handler exposes an administrative demonstration method named
deleteAll.
The following wire event was supplied:
deleteAll: pwned-method-invocation
Observed output:
MethodReader invoked event-selected method:
deleteAll:pwned-method-invocation
This confirms that the event name supplied in the wire message selected the
corresponding public handler method and that the attacker-controlled
argument was delivered to that method.
The demonstration method does not perform destructive deletion. Its purpose
is to establish that an operation exposed by the registered handler can be
selected directly through the incoming event name.
File-Reading Method Invocation
The handler additionally exposes a demonstration method that reads a
caller-specified system file.
The supplied event was:
readSystemFile: /etc/hosts
Observed invocation:
MethodReader invoked file-reading method:
readSystemFile:/etc/hosts
The handler successfully accessed the supplied file and recorded:
MethodReader file-read evidence:
/etc/hosts:bytes=279:first-line=##
The test therefore demonstrates more than method-name resolution. The
externally supplied event selected a file-access operation and the
externally supplied argument controlled the path processed by that
operation.
Automatic Exposure of Newly Added Handler Methods
A new public method was added to the registered handler interface:
void pingLocalhost(int port);
No individual MethodReader registration was added for pingLocalhost.
The following wire event was then supplied:
pingLocalhost: 61866
Observed output:
MethodReader invoked loopback ping method:
pingLocalhost:61866
The test additionally recorded the resulting loopback interaction:
MethodReader loopback ping evidence:
pingLocalhost:127.0.0.1:61866
This confirms that adding the method to the registered handler interface
was sufficient for the operation to become part of the MethodReader
dispatch surface.
The test is significant because it demonstrates that the callable surface
can expand as the handler interface evolves. A newly introduced public
handler operation does not require separate method-level registration
before it can be selected by a corresponding wire event.
Process-Execution Demonstration
The automatic dispatch behavior was further tested with a deliberately
introduced handler method containing a process-execution operation:
void runtimeExecEcho(String command);
The following event was supplied:
runtimeExecEcho: pwned-runtime-exec
Observed invocation:
MethodReader invoked Runtime.exec method:
runtimeExecEcho:pwned-runtime-exec
The test recorded successful process execution:
MethodReader Runtime.exec evidence:
command=/bin/echo pwned-runtime-exec, exit=0
Process output:
pwned-runtime-exec
This test does not establish that Chronicle Wire itself contains a built-in
command-execution method or universal RCE gadget. The runtimeExecEcho
method was intentionally introduced as a controlled demonstration of the
security consequence when a privileged operation exists on a registered
handler interface.
The result confirms the underlying dispatch property: once the public
method was present on the handler interface, the corresponding wire event
could select and invoke it without separate method-level registration.
Typed Object Argument Deserialization
The PoC additionally demonstrates that MethodReader dispatch can interact
with Chronicle Wire's typed object deserialization when a handler accepts a
sufficiently broad parameter type.
The supplied event contained a tagged object:
acceptObject:
!net.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe {
marker: proof
}
Observed output:
MethodReader typed argument instantiated class:
net.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe
MethodReader typed argument constructor calls: 1
MethodReader typed argument readMarshallable calls: 1
This confirms that MethodReader did not simply pass a textual
representation of the supplied argument to the handler.
The argument entered Chronicle Wire's object deserialization path, the
class identified by the serialized type information was instantiated, its
constructor executed, and its readMarshallable() callback was invoked.
For handler methods accepting broad or polymorphic parameter types,
externally controlled wire input may therefore influence both the handler
operation selected for invocation and the runtime object created as its
argument.
PoC Results
The runtime evidence confirms the following MethodReader behaviors:
[CONFIRMED] Wire event selected deleteAll handler method
[CONFIRMED] Attacker-controlled argument delivered to selected method
[CONFIRMED] Wire event selected readSystemFile handler method
[CONFIRMED] Supplied /etc/hosts path processed by handler
[CONFIRMED] File contents successfully read
[CONFIRMED] Newly added pingLocalhost method became dispatchable
[CONFIRMED] No separate method-level registration was required
[CONFIRMED] Loopback network interaction occurred
[CONFIRMED] Newly added runtimeExecEcho method became dispatchable
[CONFIRMED] Demonstration process executed successfully
[CONFIRMED] /bin/echo exited with status 0
Severity
No CVSS data available.
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| unknown | Chronicle Wire |
Affected:
unknown
|
guessed |
{
"containers": {
"cna": {
"affected": [
{
"product": "Chronicle Wire",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ron E"
}
],
"descriptions": [
{
"lang": "en",
"value": "Chronicle Wire\u0027s MethodReader implements message dispatch by dynamically\nmapping serialized wire events to Java handler methods. During\ninitialization, the framework discovers public methods exposed by the\nregistered handler interfaces and registers those methods as callable wire\nevents.\n\nWhen a message is processed, the event name supplied within the wire data\ndetermines which registered handler method is selected. Method arguments\nare then deserialized from the corresponding message content, and Chronicle\nWire invokes the selected method using Java Reflection.\n\nAs a result, when untrusted wire data reaches a MethodReader, externally\ncontrolled input can determine both the handler method selected for\ninvocation and the arguments supplied to that method.\n\nThe dispatch surface is derived automatically from the handler\u0027s public\ninterface rather than from an explicit list of individually registered\noperations. Public methods added to a registered handler interface can\ntherefore become dispatchable wire events without separate method-level\nregistration.\n\nThis behavior becomes security-sensitive when a handler interface contains\nprivileged or security-sensitive operations and its MethodReader processes\ndata from an untrusted source. In such deployments, methods intended for\nfile access, network operations, key management, maintenance,\nadministrative functionality, or other privileged actions may become\nreachable through externally controlled event names.\nVulnerability Details\n\nVanillaMethodReader constructs its dispatch surface from the handlers\nsupplied by the application:\n\naddParsersForComponents(handler);\n\nDuring initialization, Chronicle Wire enumerates the public methods\nassociated with the handler:\n\nfor (Method method : handlerClass.getMethods()) {\n addParseletForMethod(method);\n}\n\nEligible methods are subsequently registered for wire-event dispatch.\n\nThe method name and parameter types are used to construct the corresponding\nwire key:\n\nMethodWireKey key =\n new MethodWireKey(\n method.getName(),\n parameterTypes);\n\nThis means the set of methods callable through the wire protocol is derived\nfrom the public methods exposed by the registered handler interface.\n\nWhen incoming wire data is processed, the supplied event name is matched\nagainst the registered method dispatch table. The corresponding argument\nvalues are then deserialized according to the selected method\u0027s declared\nparameter types:\n\narguments[i] =\n valueIn.object(parameterTypes[i]);\n\nAfter argument deserialization, the selected Java method is invoked\nreflectively:\n\nmethod.invoke(target, arguments);\n\nConsequently, externally controlled wire data participates directly in two\nsecurity-sensitive decisions: selecting which registered handler method is\nexecuted and supplying the arguments passed to that method.\n\nThe dispatch mechanism itself does not introduce a method-level\nauthorization decision between event selection and invocation. The\neffective security boundary is therefore determined by which interfaces are\nregistered with MethodReader, which public methods those interfaces expose,\nand whether the application permits untrusted data to reach the reader.\nRoot Cause\n\nThe security issue arises from automatically deriving the externally\ndispatchable method surface from public methods exposed by registered\nhandler interfaces.\n\nChronicle Wire:\n\n -\n\n Discovers public methods associated with registered handlers.\n -\n\n Registers eligible methods as wire-event handlers.\n -\n\n Resolves incoming event names to those methods.\n -\n\n Deserializes method parameters from the corresponding wire input.\n -\n\n Invokes the selected methods using Java Reflection.\n\nThe dispatch model does not require each callable operation to be\nindependently exported or registered at the method level. Consequently, the\nsecurity boundary of a MethodReader can expand when additional public\nmethods are introduced into an interface already used for wire dispatch.\n\nThis creates a risk in applications where the registered handler interface\ncontains operations that should not be reachable by the party controlling\nthe wire input.\n\nThe issue is particularly significant when interfaces evolve over time.\nAdding a new public operation to an existing MethodReader-facing interface\ncan simultaneously add that operation to the wire dispatch surface without\na separate dispatch registration step.\nImpact\n\nWhen untrusted input reaches a MethodReader, an attacker can select among\nthe public operations exposed through the registered handler interface and\nprovide serialized arguments for the selected operation.\n\nThe resulting security impact depends on the functionality implemented by\nthose handlers.\n\nSecurity-sensitive methods may include:\n\n -\n\n file access and file modification;\n -\n\n outbound network communication;\n -\n\n administrative operations;\n -\n\n key rotation or key-management operations;\n -\n\n configuration changes;\n -\n\n maintenance functionality;\n -\n\n state-changing business operations; and\n -\n\n other privileged application functionality.\n\nIf such operations are exposed through a registered handler interface,\nexternally controlled event names can cause those methods to be invoked\nwith externally supplied arguments.\n\nThe attack surface can also change as the application evolves. A public\nmethod added to an interface already participating in MethodReader dispatch\nmay become a new wire operation without requiring separate registration of\nthat individual method.\n\nMethods accepting broad or polymorphic argument types introduce an\nadditional concern. Arguments are processed through Chronicle Wire\u0027s object\ndeserialization mechanisms:\n\narguments[i] =\n valueIn.object(parameterTypes[i]);\n\nWhere the declared parameter type permits serialized type information to\ninfluence runtime object selection, externally controlled input may affect\nboth the *method selected for invocation* and the *runtime object\ninstantiated as its argument*.\n\nThe resulting vulnerability therefore combines an externally controlled\nmethod-dispatch surface with attacker-controlled argument deserialization.\nThe ultimate impact depends on the operations exposed by the registered\nhandler and the trust boundary through which wire messages are received.\n\nProof of Concept\n\nThe proof of concept demonstrates that Chronicle Wire\u0027s MethodReader allows\nserialized event names to select public methods exposed by a registered\nhandler and supplies those methods with arguments deserialized from the\ncorresponding wire message.\n\nThe tests exercise several handler operations to demonstrate method\nselection, privileged-operation reachability, automatic expansion of the\ndispatch surface, and typed argument deserialization.\nAdministrative Method Invocation\n\nThe registered handler exposes an administrative demonstration method named\ndeleteAll.\n\nThe following wire event was supplied:\n\ndeleteAll: pwned-method-invocation\n\nObserved output:\n\nMethodReader invoked event-selected method:\ndeleteAll:pwned-method-invocation\n\nThis confirms that the event name supplied in the wire message selected the\ncorresponding public handler method and that the attacker-controlled\nargument was delivered to that method.\n\nThe demonstration method does not perform destructive deletion. Its purpose\nis to establish that an operation exposed by the registered handler can be\nselected directly through the incoming event name.\nFile-Reading Method Invocation\n\nThe handler additionally exposes a demonstration method that reads a\ncaller-specified system file.\n\nThe supplied event was:\n\nreadSystemFile: /etc/hosts\n\nObserved invocation:\n\nMethodReader invoked file-reading method:\nreadSystemFile:/etc/hosts\n\nThe handler successfully accessed the supplied file and recorded:\n\nMethodReader file-read evidence:\n/etc/hosts:bytes=279:first-line=##\n\nThe test therefore demonstrates more than method-name resolution. The\nexternally supplied event selected a file-access operation and the\nexternally supplied argument controlled the path processed by that\noperation.\nAutomatic Exposure of Newly Added Handler Methods\n\nA new public method was added to the registered handler interface:\n\nvoid pingLocalhost(int port);\n\nNo individual MethodReader registration was added for pingLocalhost.\n\nThe following wire event was then supplied:\n\npingLocalhost: 61866\n\nObserved output:\n\nMethodReader invoked loopback ping method:\npingLocalhost:61866\n\nThe test additionally recorded the resulting loopback interaction:\n\nMethodReader loopback ping evidence:\npingLocalhost:127.0.0.1:61866\n\nThis confirms that adding the method to the registered handler interface\nwas sufficient for the operation to become part of the MethodReader\ndispatch surface.\n\nThe test is significant because it demonstrates that the callable surface\ncan expand as the handler interface evolves. A newly introduced public\nhandler operation does not require separate method-level registration\nbefore it can be selected by a corresponding wire event.\nProcess-Execution Demonstration\n\nThe automatic dispatch behavior was further tested with a deliberately\nintroduced handler method containing a process-execution operation:\n\nvoid runtimeExecEcho(String command);\n\nThe following event was supplied:\n\nruntimeExecEcho: pwned-runtime-exec\n\nObserved invocation:\n\nMethodReader invoked Runtime.exec method:\nruntimeExecEcho:pwned-runtime-exec\n\nThe test recorded successful process execution:\n\nMethodReader Runtime.exec evidence:\ncommand=/bin/echo pwned-runtime-exec, exit=0\n\nProcess output:\n\npwned-runtime-exec\n\nThis test does not establish that Chronicle Wire itself contains a built-in\ncommand-execution method or universal RCE gadget. The runtimeExecEcho\nmethod was intentionally introduced as a controlled demonstration of the\nsecurity consequence when a privileged operation exists on a registered\nhandler interface.\n\nThe result confirms the underlying dispatch property: once the public\nmethod was present on the handler interface, the corresponding wire event\ncould select and invoke it without separate method-level registration.\nTyped Object Argument Deserialization\n\nThe PoC additionally demonstrates that MethodReader dispatch can interact\nwith Chronicle Wire\u0027s typed object deserialization when a handler accepts a\nsufficiently broad parameter type.\n\nThe supplied event contained a tagged object:\n\nacceptObject:\n !net.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe {\n marker: proof\n }\n\nObserved output:\n\nMethodReader typed argument instantiated class:\nnet.openhft.chronicle.wire.SecurityAdditionalPoCTest$MethodReaderProbe\n\nMethodReader typed argument constructor calls: 1\n\nMethodReader typed argument readMarshallable calls: 1\n\nThis confirms that MethodReader did not simply pass a textual\nrepresentation of the supplied argument to the handler.\n\nThe argument entered Chronicle Wire\u0027s object deserialization path, the\nclass identified by the serialized type information was instantiated, its\nconstructor executed, and its readMarshallable() callback was invoked.\n\nFor handler methods accepting broad or polymorphic parameter types,\nexternally controlled wire input may therefore influence both the handler\noperation selected for invocation and the runtime object created as its\nargument.\nPoC Results\n\nThe runtime evidence confirms the following MethodReader behaviors:\n\n[CONFIRMED] Wire event selected deleteAll handler method\n[CONFIRMED] Attacker-controlled argument delivered to selected method\n\n[CONFIRMED] Wire event selected readSystemFile handler method\n[CONFIRMED] Supplied /etc/hosts path processed by handler\n[CONFIRMED] File contents successfully read\n\n[CONFIRMED] Newly added pingLocalhost method became dispatchable\n[CONFIRMED] No separate method-level registration was required\n[CONFIRMED] Loopback network interaction occurred\n\n[CONFIRMED] Newly added runtimeExecEcho method became dispatchable\n[CONFIRMED] Demonstration process executed successfully\n[CONFIRMED] /bin/echo exited with status 0\n"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/102"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/102"
},
{
"url": "https://github.com/ob1sec"
},
{
"url": "https://linkedin.com/in/yourhandle"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/ronedgerson1"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/102"
],
"discovery": "EXTERNAL"
},
"title": "Chronicle Wire v2026.8 Insecure Reflection Allows Unvalidated Method Invocation",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0074",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/102",
"automated": true,
"contentSha256": "bbe8e54d524a45f120a262f1513e18e475b3fd19d5803ec612ee1b582cd7d0c1",
"evidenceScore": 7,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/102",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T12:42:03Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0074"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…