Back to Blog
high SEVERITY3 min read

Spring Boot Actuator Wildcard Exposure in 2021.04 Provisioning

A misconfigured Spring Boot Actuator in the ArkCase 2021.04 provisioning template exposed all management endpoints through wildcard inclusion. The fix narrows exposure to health and info endpoints only, eliminating unauthenticated access to sensitive runtime data.

O
By Orbis AppSec
Published September 23, 2026Reviewed September 23, 2026

Answer Summary

The affected code is the `application-2021.04.yaml` provisioning template used for ArkCase deployments. An attacker could retrieve heap dumps, environment variables, and log files without authentication through fully exposed Actuator endpoints. The fix changes `management.endpoints.web.exposure.include` from wildcard `'*'` to explicit `health,info`. This is a first-party configuration fix with no CVE assigned. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Vulnerability at a Glance

cweCWE-200
fixRestrict to explicit `health,info` endpoints
riskUnauthenticated access to heap dumps, environment secrets, and application logs
languageYAML (Spring Boot configuration)
root causeWildcard `'*'` value in `management.endpoints.web.exposure.include`
vulnerabilitySpring Boot Actuator overexposure

Affected Versions

Affected application-2021.04.yaml provisioning template (2021.04 release series)
Fixed in Commit hardening the exposure configuration
Ecosystem Spring Boot (YAML configuration)
CVE / GHSA not assigned
CWE CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

The Vulnerability Explained

Spring Boot Actuator provides production-ready operational endpoints for monitoring and managing applications. The management.endpoints.web.exposure.include property controls which of these endpoints are accessible via HTTP. When set to the wildcard value '*', every Actuator endpoint becomes reachable—including those designed for diagnostic access that leak sensitive runtime state.

The vulnerable configuration:

management:
  endpoints:
    web:
      exposure:
        include: '*'

This single line exposed the application's internals without authentication. An attacker—or anyone with network access—could retrieve:

  • /actuator/env: Environment variables, including database credentials, API keys, and secrets injected through SPRING_APPLICATION_JSON or shell environment
  • /actuator/logfile: The complete application log stream, potentially containing PII, session identifiers, or authentication tokens
  • /actuator/heapdump: A binary dump of the entire JVM heap, extractable offline to recover in-memory secrets, session objects, and cryptographic material
  • /actuator/threaddump: Live thread state revealing internal request handling, synchronization patterns, and potentially sensitive data on stack frames

The provisioning template's purpose—automated Vagrant environment setup—meant this configuration propagated to development and potentially staging deployments. While production might layer additional network controls, the configuration itself assumed no authentication boundary existed.

The Fix

The remediation replaces the wildcard with an explicit allowlist:

management:
  endpoints:
    web:
      exposure:
        include: 'health,info'

This change implements two critical boundaries:

  1. Principle of least exposure: Only health and info endpoints remain reachable. The health endpoint provides binary up/down status and basic health indicators; info exposes static build metadata—neither reveals runtime secrets or mutable state.

  2. Fail-closed configuration: Future Actuator endpoints added by Spring Boot upgrades won't automatically expose themselves. The explicit list requires conscious review to expand.

The health endpoint remains valuable for load balancer health checks and container orchestration probes without authentication. The info endpoint supports deployment verification through static properties like build.version and build.time. All diagnostic and sensitive operations now require explicit reconfiguration or alternative access mechanisms (JMX, authenticated HTTP, or direct JVM attachment).

Key Takeaways

  • Wildcard exposure in Actuator is never safe for network-facing services: The '*' value was designed for local development with JMX or no security context. Any YAML configuration setting this value on management.endpoints.web.exposure.include requires immediate audit.

  • Provisioning templates are production code: Infrastructure-as-code configurations propagate to real environments. The application-2021.04.yaml template served automated deployment, making its security properties binding on all generated instances.

  • Actuator endpoints have asymmetric sensitivity: health and info are intentionally safe for unauthenticated access; env, heapdump, and logfile assume privileged access. Mixing these in wildcard exposure ignores this design boundary.

  • Defense-in-depth applies to configuration: Even where network segmentation might limit exploitability, explicit endpoint restrictions prevent configuration drift from becoming vulnerability exposure.

How Orbis AppSec Detected This

Orbis AppSec identified this vulnerability through static analysis of YAML configuration files:

Element Detail
Source The management.endpoints.web.exposure.include property value
Sink HTTP exposure of Actuator endpoints to unauthenticated requests
Missing control Explicit endpoint filtering or Spring Security integration
CWE CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Fix Replace wildcard '*' with explicit 'health,info' endpoint list

The detection pattern matches Spring Boot configuration properties where management.endpoints.web.exposure.include contains '*' without accompanying management.server.port isolation or spring.security authentication requirements.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

The include: '*' pattern in Spring Boot Actuator configuration represents a silent security regression—functional for operations, catastrophic for confidentiality. This fix in the ArkCase 2021.04 provisioning template demonstrates that configuration hygiene matters as much as code security. Explicit endpoint exposure, not wildcard convenience, should govern production-ready Spring Boot deployments.

Prevention and further reading

Frequently Asked Questions

Why was the `include: '*'` pattern considered defense-in-depth rather than an exploitable vulnerability in this specific template?

The provisioning template is used during Vagrant-based development deployments, so the actual exploitability depended on network exposure of those environments. The fix makes the security boundary explicit regardless of deployment context, ensuring production-like configurations don't inherit the wildcard pattern.

Does the fixed `include: 'health,info'` configuration prevent custom Actuator endpoints from functioning?

Custom endpoints remain available if explicitly registered, but the `web.exposure.include` property only controls which built-in endpoints are exposed over HTTP. Custom endpoints require separate `@Endpoint` or `@WebEndpointExtension` annotations and their own exposure configuration.

Which specific Actuator endpoints were reachable before the fix that are now blocked?

The wildcard exposed `/actuator/env` (environment variables including secrets), `/actuator/logfile` (application logs), `/actuator/heapdump` (JVM heap dump), `/actuator/metrics` (runtime metrics), and `/actuator/threaddump` among others—only `/actuator/health` and `/actuator/info` remain exposed after the fix.

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #710

Related Articles

critical

deleteNestedProperty Prototype Pollution via Dot-Notation Path

The `deleteNestedProperty` function in propertyUtils.ts allowed attackers to manipulate JavaScript object prototypes by passing specially crafted dot-notation paths like `__proto__.polluted`. A fix now blocks dangerous keys before processing, preventing prototype pollution attacks that could affect all objects in the application.

high

How Denial of Service via Infinite Loop Happens in JavaScript Dependencies and How to Fix It

CVE-2026-67213 is a high-severity denial of service vulnerability in nanoid before version 5.1.6 that triggers an infinite loop during random ID generation when processing specially crafted input. We upgraded nanoid across the entire dependency tree to patch this flaw and prevent attackers from freezing application threads. This fix ensures that ID generation remains resilient even when handling adversarial input patterns.

high

How Sensitive Data Exposure happens in Zotero plugins and how to fix it

A high-severity data exposure vulnerability in `Zotero.ts` automatically transmitted complete document metadata—including private notes, attachment paths, and tags—to external LLM services without user consent. The fix replaces broad `item.toJSON()` serialization with explicit field selection, sending only essential bibliographic data.

high

How missing dependency update cooldowns happen in GitHub Dependabot configurations and how to fix it

A semgrep scan flagged `.github/dependabot.yml` for lacking a cooldown period, meaning Dependabot would immediately propose updates to brand-new package versions across npm, Bundler, and Docker ecosystems. The fix adds a `cooldown: default-days: 7` block to every `package-ecosystem` entry, forcing a one-week waiting period before newly published releases are considered — reducing exposure to malicious or unstable package drops.

high

How Path Traversal Happens in TensorFlow's Data Service and How to Fix It

TensorFlow's data service dispatcher validated dataset IDs against forward-slash traversal attacks but overlooked backslash characters on non-Windows platforms, allowing attackers to escape the root directory. A targeted fix adds explicit backslash validation across all platforms, closing a high-severity path traversal vulnerability in the snapshot management system.

high

updateCardBg() Follows Unvalidated 302 Location Headers

A background-image updater fetched a configured image URL with manual redirect handling and then re-issued the request to whatever `Location` header came back, with no scheme or host checks. A redirect to `http://169.254.169.254/` or `http://127.0.0.1:<port>/` would have been followed with the original fetch options attached, and the response body written to disk as an image asset. The fix resolves the redirect target against `imgDownloadUrl` and rejects anything that is not HTTPS on the same ho