Object Factory

How object factories work in JNDI resolution

An object factory is the last-mile conversion step in a JNDI lookup. It takes reference data and returns a live object, which is useful for wiring resources, but it also means the lookup path can do more than simple name resolution.

The important security point is that the factory is not the problem by itself. The risk appears when the application allows an untrusted lookup path, untrusted attributes, or an attacker-influenced factory class name to drive object creation. In that case, the lookup flow can cross from passive resolution into active code execution or unsafe deserialization-like behaviour.

This pattern is why object factories sit at the boundary between naming services and application runtime behaviour. Once a reference can influence reflection, method invocation, or expression evaluation, the factory is no longer just a data adapter, it becomes an execution pivot.

Why object factories become dangerous

Object factories become dangerous when the factory implementation trusts metadata that should have stayed inert. A legitimate reference can be enough to trigger unexpected behaviour if the application permits arbitrary or attacker-controlled attributes to reach a factory that was never meant to process hostile input.

That risk is amplified because the dangerous step often happens indirectly. Developers may think they are only resolving a directory entry or Java naming reference, when in reality the lookup may instantiate classes, evaluate expressions, or call methods on supplied values. OWASP API Security Top 10 is useful here as a reminder that input accepted by an interface must be treated as a trust decision, not just a transport detail.

In practical terms, the hazard is not limited to obviously malicious factories. A normal factory can be abused if it is reachable through a broad resolution path, which is why the surrounding application boundary matters as much as the factory code itself.

Common abuse patterns and failure modes

The most common failure mode is gadget-like behaviour hidden inside a legitimate integration. If the factory performs reflection, invokes methods dynamically, or evaluates expressions from reference attributes, an attacker may be able to steer the runtime toward an unexpected class, method, or payload.

Another failure mode is mis-scoped trust in JNDI providers or reference metadata. When application code assumes that all JNDI data is internal and benign, the lookup path can become a supply path for arbitrary object construction. For broader control thinking, NIST Cybersecurity Framework 2.0 aligns well because the issue spans governance, protection, detection, and recovery around a fragile trust boundary.

When the factory sits in a component used across many services, one weakness can propagate widely. That makes the issue more than a coding bug, it is an architecture and trust-boundary problem that can affect several application paths at once.

How practitioners should interpret object factory risk

Why practitioners should care: object factories are easy to overlook because they sound like simple plumbing, yet they can transform remote reference data into executable behaviour. That makes them a high-value review point wherever naming, directory, or reference-based resolution is present.

Common misunderstanding: developers often focus on whether the factory class is trusted, when the real question is whether the input path to that class is trusted. A safe factory can still be abused if attacker-controlled attributes decide what it builds or how it behaves.

Practitioner note: the most useful mental model is to treat object factories as part of the application’s execution surface, not just its configuration surface. Review them the same way you would any component that can cross from data into behaviour.

Risk and Threat Considerations

Object factories create a narrow but serious attack surface because they sit where passive reference data can become active runtime behaviour. If an attacker can influence the reference, the target object, or the attributes fed into the factory, they may trigger code paths that were never intended for untrusted input.

Failure mechanism: the lookup process accepts attacker-shaped reference data and passes it into a factory that performs reflection, method invocation, or expression evaluation, turning a naming resolution step into an execution path.

Impact: the result can include arbitrary object instantiation, unsafe method execution, application compromise, or follow-on access to sensitive resources that the lookup process was never meant to expose.

Related resources from NHI Mgmt Group

• What is the difference between scope-based authorization and object-level authorization in MCP?
• What is the difference between a code assistant and an autonomous code factory?
• What breaks when contractor access is not tightly governed on the factory floor?
• When should organisations choose a factory reset instead of in-place migration?