CAPEC-36
Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
On this page
Adversaries can also search for undocumented bits on a hardware device, commonly known as "chicken bits". These bits are used to enable/disable certain functionality, but are not published. Adversaries can reverse engineer firmware to identify hidden features and change these bits at runtime to achieve malicious behavior.
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-36: Using Unpublished Interfaces or Functionality: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/36.html and https://cve.bz/cve/capec/36?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Explore
The attacker looks for a way in.
[Identify services] Discover a service of interest by exploring service registry listings or by connecting on a known port or some similar means.
3 techniques
- Search via internet for known, published services.
- Use automated tools to scan known ports to identify internet-enabled services.
- Dump the code from the chip and then perform reverse engineering to analyze the code.
[Authenticate to service] Authenticate to the service, if required, in order to explore it.
3 techniques
- Use published credentials to access system.
- Find unpublished credentials to access service.
- Use other attack pattern or weakness to bypass authentication.
[Identify all interfaces] Determine the exposed interfaces by querying the registry as well as probably sniffing to expose interfaces that are not explicitly listed.
2 techniques
- For any published services, determine exposed interfaces via the documentation provided.
- For any services found, use error messages from poorly formed service calls to determine valid interfaces. In some cases, services will respond to poorly formed calls with valid ones.
Experiment
They probe what they found.
[Attempt to discover unpublished functions] Using manual or automated means, discover unpublished or undocumented functions exposed by the service.
2 techniques
- Manually attempt calls to the service using an educated guess approach, including the use of terms like' 'test', 'debug', 'delete', etc.
- Use automated tools to scan the service to attempt to reverse engineer exposed, but undocumented, features.
Exploit
They carry out the attack.
[Exploit unpublished functions] Using information determined via experimentation, exploit the unpublished features of the service.
2 techniques
- Execute features that are not intended to be used by general system users.
- Craft malicious calls to features not intended to be used by general system users that take advantage of security flaws found in the functions.
Prerequisites
The architecture under attack must publish or otherwise make available services that clients can attach to, either in an unauthenticated fashion, or having obtained an authentication token elsewhere. The service need not be 'discoverable', but in the event it isn't it must have some way of being discovered by an attacker. This might include listening on a well-known port. Ultimately, the likelihood of exploit depends on discoverability of the vulnerable service.
Skills required
- Low skill
A number of web service digging tools are available for free that help discover exposed web services and their interfaces. In the event that a web service is not listed, the attacker does not need to know much more in addition to the format of web service messages that they can sniff/monitor for.
Resources required
None: No specialized resources are required to execute this type of attack. Web service digging tools may be helpful.
Consequences
| Impact | Affects | Note |
|---|---|---|
| Read Data | Confidentiality | |
| Gain Privileges | Confidentiality, Access Control, Authorization |
Mitigations
Authenticating both services and their discovery, and protecting that authentication mechanism simply fixes the bulk of this problem. Protecting the authentication involves the standard means, including: 1) protecting the channel over which authentication occurs, 2) preventing the theft, forgery, or prediction of authentication credentials or the resultant tokens, or 3) subversion of password reset and the like.
Weaknesses it exploits
- CWE-306 Missing Authentication for Critical Functionality
- CWE-693 Protection Mechanism Failure
- CWE-695 Use of Low-Level Functionality
- CWE-1242 Inclusion of Undocumented Features or Chicken Bits
Recent CVEs with these weaknesses
- –CVE-2026-97870
When Hessian remoting endpoints are served by the embedded HTTP server, configured authentication and transport security requirements are silently ignored. A remote unauthenticated attacker can invoke the exposed EJB methods without creden…
- –CVE-2026-97872
When an EJB is exposed over the optional Hessian protocol inside an existing web application, some configured authentication and transport security settings are silently not enforced. A remote unauthenticated attacker can invoke the expose…
- 9.4CVE-2026-121683
Missing authentication in Ivanti Cloud Services Application version 5.0.8 allows a remote unauthenticated attacker to add and delete arbitrary trusted EPM Core certificate entries.
- –CVE-2026-111251
The admin service of the standalone OpenEJB server accepts stop requests without any authentication. Any local user or process able to connect to the admin port can stop the server, leading to denial of service; the admin service is enable…
- –CVE-2026-111256
When JAX-WS or JAX-RS endpoints are published by the embedded OpenEJB HTTP server rather than Tomcat, some configured authentication methods are silently ignored and the endpoint is published without authentication. A remote unauthenticate…
- –CVE-2026-87756
The internal system EJBs used for remote deployment and configuration did not enforce their administrative role check when the server ran with the default profile. A remote unauthenticated attacker able to reach the remote EJB endpoint cou…
- –CVE-2026-111263
Authentication configured for an EJB JAX-WS endpoint in the TomEE deployment descriptor is not enforced when the endpoint is published within an existing web application. A remote unauthenticated attacker can invoke the web service operati…
- 7.5CVE-2026-95651
Zoho Corporation ManageEngine DDI Central versions 6500 and below are vulnerable to an unauthenticated GSS-TSIG keytab update vulnerability in the Linux Node Agent.
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-113 Interface Manipulation
Examples
To an extent, Google services (such as Google Maps) are all well-known examples. Calling these services, or e…
To an extent, Google services (such as Google Maps) are all well-known examples. Calling these services, or extending them for one's own (perhaps very different) purposes is as easy as knowing they exist. Their unencumbered public use, however, is a purposeful aspect of Google's business model. Most organizations, however, do not have the same business model. Organizations publishing services usually fall back on thoughts that Attackers "will not know services exist" and that "even if they did, they wouldn't be able to access them because they're not on the local LAN." Simple threat modeling exercises usually uncovers simple attack vectors that can invalidate these assumptions.
MITRE's words, unchanged: CAPEC-36 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.