In the early days, we benchmarked Hacktron’s capabilities to browse large codebases and find exploitable vulnerabilities. We focused on real-world codebases that we had previously audited, as prior knowledge helps triage and eliminate false positives.
Delmia Apriso is a manufacturing execution system. At one point Apple hosted it externally, and Boeing, Airbus France, and Lockheed Martin are among its users. Synacktiv and I (while at ProjectDiscovery) have audited its code. Its backend is .NET and the codebase is relatively large, which made it a good candidate for benchmarking Hacktron.
Hacktron ended up finding CVE-2025-5086, a pre-auth remote code execution vulnerability with a 9.0 CVSS severity rating.
Hacktron’s environment and objective
Knowing a few things about .NET, we provided Hacktron with the decompiled source code and the webroot/install directory contents, since configuration files such as web.config are there and apply based on directory structure:
➜ DELMIA-Apriso-2025 ls
flexnet_decompiled_dlls install_dir_contents
We provided Hacktron with the following objective:
Objective
You’re reviewing the C#/ASP.NET-based codebase of a web application called
Delmia Apriso FlexNet. The goal is to assess the application for any
unauthenticated insecure deserialization risks, especially those that could be
triggered through user-controllable input. Focus on identifying patterns where
external data is processed in ways that might lead to unsafe deserialization,
particularly in the absence of strong validation or protective controls.
After embedding our own knowledge into Hacktron, we wanted to see how it approaches and flags bugs and whether that matches how we would think through an audit ourselves.
Tracing deserialization sinks
Here is how Hacktron thinks about the code:
Thinking
Let’s search for all occurrences of .Deserialize(...) across .cs files. This should reveal common sinks like BinaryFormatter, XmlSerializer, or custom deserializers.
This led to many sinks and multiple paths for Hacktron to explore. One example:
In other words, it’s just a thin wrapper over JsonConvert.DeserializeObject(...). Hacktron checked whether this JSON call uses any unsafe settings, such as TypeNameHandling. JSON deserialization is usually safe, but if TypeNameHandling is enabled anywhere, an attacker can inject arbitrary types, so it searched the whole codebase for it:
Thinking
This looks like a custom JSON-based deserializer. By default, JsonConvert.DeserializeObject uses TypeNameHandling = None (safe). There’s no JsonSerializerSettings passed here, so nested objects simply get re-parsed recursively. We’d need TypeNameHandling.All (or similar) to let the client dictate type information. Let’s search globally for any TypeNameHandling references.
Since no TypeNameHandling reference was found, Hacktron assumed the default setting (TypeNameHandling = None) applies. With that pathway ruled out, it marked this as a dead end and moved on to investigate other parts of the source code.
Thinking
I haven’t found any clear instances of BinaryFormatter.Deserialize or JsonConvert.DeserializeObject with TypeNameHandling enabled that are reachable from unauthenticated user input. The XmlSerializer path seems constrained by the server-side type definition. The Runtime.Deserialize path leads to code I cannot analyze. The SfControllerExtender path using JsonConvert seems safe due to default settings, and I couldn’t trace its origin anyway.
Perhaps I should look for other potentially dangerous serializers like LosFormatter, ObjectStateFormatter, or NetDataContractSerializer.
Finding NetDataContractSerializer
As Hacktron navigates deeper through the codebase, it comes across FlexNetOperationsService.cs.
It detects NetDataContractSerializer, a serializer that embeds .NET type metadata and is dangerous when fed untrusted input.
Thinking
Okay, this is interesting! NetDataContractSerializer is explicitly mentioned via the [NetDataContractSerializerBehavior] attribute applied to the FlexNetOperationsService class in /app/FlexNet.WebUI.WebServices/FlexNetOperationsService.cs.
NetDataContractSerializer is dangerous because, like BinaryFormatter, it includes .NET type information in the serialized data (XML in this case), allowing an attacker to potentially control the type being deserialized. If this service endpoint is reachable without authentication and processes user-supplied data using this serializer, it could lead to arbitrary object deserialization and RCE.
I need to examine FlexNetOperationsService.cs to understand:
What methods does this service expose?
Do any methods take parameters that are deserialized using NetDataContractSerializer?
Is the service accessible without authentication?
Looking at the attributes applied to the FlexNetOperationsService class and the Invoke method:
The hypothesis below is the interesting part. Hacktron noticed that the WCF service has no auth annotations and that the binding is in web.config, but the service definition is commented out. Would it still be reachable?
Thinking
There are no standard ASP.NET or WCF authorization attributes like [Authorize] or [AllowAnonymous] applied to either the class or the method. In WCF, the absence of explicit security configuration in web.config and the lack of authorization attributes in the code often defaults to no authentication.
Thinking
This main web.config for the /WebServices/ directory provides more context:
FlexNetOperationsService.svc Binding: Lines 64-71 show a commented-out service definition for FlexNet.FunctionInterpreter.WebServices.FlexNetOperationsService. If this were active, it would use the wsHttpBinding named FlexNetConfiguration.
FlexNetConfiguration Binding: Lines 84-90 define the wsHttpBinding named FlexNetConfiguration. Crucially, it confirms <securitymode="None">.
Service Implementation: The service implementation class is FlexNet.FunctionInterpreter.WebServices.FlexNetOperationsService.
Hypothesis: Although the service definition for FlexNetOperationsService.svc is commented out in web.config, the .svc file itself exists (/app/install_dir_contents/WebSite/WebServices/FlexNetOperationsService.svc). It’s possible that the service is activated by the presence of the .svc file.
Reporting
Confirming that the service can be accessed pre-auth and does allow deserialization, Hacktron reported the issue to us:
GitHub issue #22 reporting unauthenticated arbitrary deserialization in FlexNetOperationsService
We validated the vulnerability and confirmed RCE via the unauthenticated request below:
PoC HTTP Request
1
POST /apriso/WebServices/FlexNetOperationsService.svc/Invoke?cmd=dir HTTP/1.1
