This is a deadbolt that quietly leaves the side door unlocked when the key ring is missing
CVE-2026-10584 affects the proxy server in AWS Graph Explorer for versions >= 1.1.0 and < 3.0.1. When operators intend to run it over HTTPS but the certificate files are missing or certificate discovery/generation fails, the service can silently start on HTTP instead of failing closed. That turns traffic that admins thought was encrypted into cleartext, exposing graph queries, results, and any other sensitive data passing through the proxy path to interception.
The vendor's MEDIUM 5.9 is technically defensible in a lab, but it overstates enterprise urgency in the field. This is not a clean unauthenticated remote exploit that gives code execution; it is a misconfiguration-conditioned confidentiality issue that still requires an attacker to get on path to the traffic. In most real deployments, that means the attacker already controls the local network, reverse-proxy layer, Wi-Fi, or another intermediate hop, which pushes this down to LOW operational priority for broad fleet patching.
4 steps from start to impact.
Operator deploys a vulnerable build with broken TLS prerequisites
3.0.1 is deployed with HTTPS expected, but certificate generation or discovery fails because HOST is wrong, certificate files are absent, or the config directory behavior breaks the lookup path. The vulnerable startup path then continues instead of failing closed.- Graph Explorer version is >= 1.1.0 and < 3.0.1
- HTTPS is intended or enabled
- Certificate files are missing or discovery/generation fails
- Patched
3.0.1+exits instead of silently falling back - Many enterprises terminate TLS upstream and never depend on local self-signed cert generation
- Some deployments are notebook-embedded or private VPC-only rather than standalone internet services
<3.0.1, but only a live protocol probe or config review will catch the dangerous HTTP fallback symptom.Service comes up on HTTP while defenders assume HTTPS
- Clients can still reach the proxy service
- Operators do not immediately notice the protocol downgrade
- A simple
curl -I http://host/curl -kI https://hostcheck exposes the condition fast - Reverse proxies, load balancers, and HSTS at the edge can mask or neutralize the issue
On-path attacker captures traffic with standard interception tooling
tcpdump, Wireshark, mitmproxy, bettercap, or a compromised reverse proxy. This is not a cryptographic break; it is classic packet visibility caused by the application downgrading itself into cleartext.- Attacker has on-path visibility: same subnet, hostile Wi-Fi, compromised gateway, reverse proxy, ISP segment, or upstream logging point
- Traffic to Graph Explorer traverses that path in cleartext
- Requires attacker position beyond basic internet reachability
- East-west traffic inside private cloud networks is often harder to tap than public web traffic
Sensitive graph traffic is disclosed
- Captured traffic contains sensitive business or infrastructure data
- Operators rely on the proxy path for access to Neptune or other graph endpoints
- Some sessions may still have compensating auth boundaries upstream
- If the exposed dataset is low sensitivity, impact is muted even when interception succeeds
The supporting signals.
| In-the-wild status | No public exploitation evidence found in reviewed sources as of 2026-06-04. It is not in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public exploit repo or turnkey PoC found in quick-source review. Reproduction is straightforward from the advisory itself: break cert availability or discovery and observe protocol behavior. |
| EPSS | 0.00009 (user-supplied intel), which is effectively near-floor exploit likelihood. FIRST public landing page confirms methodology, but this assessment did not verify percentile directly. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog as checked on 2026-06-04. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N maps to network reachable but high-complexity confidentiality exposure. In practice, the missing CVSS nuance is the on-path attacker requirement, which is the biggest severity suppressor. |
| Affected versions | Graph Explorer >= 1.1.0 and < 3.0.1 per the AWS bulletin. |
| Fixed version | 3.0.1. Reviewed sources show no distro backport guidance; treat this as an application/container upgrade. |
| Exposure profile | No reviewed source provided Shodan/Censys/FOFA census data. *Inference from AWS docs and repo guidance:* this is a niche, containerized, admin-oriented tool commonly run in notebooks, EC2, ECS/Fargate, or local Docker, not a broad enterprise edge service. |
| Disclosure and credit | Disclosed 2026-06-02 in AWS bulletin 2026-038-AWS; acknowledgment credits Eduardo Caro. |
| Operator clue | AWS explicitly calls out the risky conditions: verify the deployment is actually serving HTTPS, set HOST correctly, and avoid non-default config directory paths when relying on automatic self-signed certificate generation. |
noisgate verdict.
The decisive factor is attacker position: this bug only matters when a vulnerable deployment also loses TLS and an attacker can then observe the traffic path. That makes it a real confidentiality problem for exposed misconfigurations, but not the kind of unauthenticated internet-scale flaw that should jump the queue across 10,000 hosts.
Why this verdict
- Requires an on-path attacker The CVE does not let a random internet host 'break TLS'; it only helps after the service has already dropped to HTTP and the attacker can observe that network path. That is a major real-world downgrade from generic
AV:Nintuition. - The vulnerable state is conditional, not default-safe You need a vulnerable version plus missing or undiscovered certificate material plus operators not noticing that the service came up on HTTP. Each prerequisite narrows the reachable population.
- Population and blast radius are limited Graph Explorer is a niche graph-visualization admin tool, often deployed in notebooks, Docker, EC2, or ECS/Fargate rather than at the hardened enterprise edge. Impact is confidentiality-only and scoped to the traffic crossing that one service path.
Why not higher?
There is no code execution, auth bypass, or direct privilege gain here. Even when exposed, the attacker still needs a network vantage point that many enterprises should already make difficult with segmentation, private VPC deployment, managed ingress, or upstream TLS termination.
Why not lower?
This is not harmless. The dangerous part is the silent nature of the fallback: operators may believe a sensitive admin/data path is protected when it is actually cleartext. If you do have a public or shared-network deployment, the confidentiality failure is very real and should be fixed, not waived away.
What to do — in priority order.
- Force TLS at the edge — Put Graph Explorer behind a reverse proxy, ALB, or ingress that terminates HTTPS and redirects/block plain HTTP. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene, but validate any internet-facing instance today because the whole issue is protocol downgrade.
- Validate startup fails closed — Test every deployed instance so missing certs produce a hard startup failure instead of a listening HTTP service. For LOW, there is no formal mitigation SLA; fold it into routine config assurance, with same-day checks for exposed systems.
- Restrict exposure — Keep Graph Explorer on private subnets, VPN-only access, or admin-only security groups rather than publishing it broadly. That reduces the number of places an on-path attacker can realistically see the traffic; for LOW, do it as normal hardening rather than emergency change unless exposure is public.
- Audit
HOSTand cert paths — Review container environment, mounted certificate files, and any non-default configuration directory usage so the startup path can actually find the expected cert material. For LOW, this is standard hygiene work and can ride the next maintenance cycle unless you discover current HTTP exposure.
- A WAF alone does not fix this; the problem is transport cleartext, not malicious payload shape.
- MFA is irrelevant to the core risk; it may protect admin login, but it does nothing if the application traffic itself is being transmitted over HTTP.
- Version-only scanning is incomplete; it tells you the software is old, but not whether the dangerous HTTP fallback condition is happening in production.
Crowdsourced verification payload.
Run this on the Docker host, VM, or Kubernetes node tooling box that has access to the Graph Explorer container image or filesystem. Invoke it as bash check_graph_explorer_cve_2026_10584.sh --container graph-explorer or bash check_graph_explorer_cve_2026_10584.sh --path /opt/graph-explorer; add --url https://graph.example.com/explorer if you also want a live HTTP/HTTPS symptom check. It needs read access only plus Docker access if you use --container.
#!/usr/bin/env bash
# check_graph_explorer_cve_2026_10584.sh
# Exit codes:
# 0 = PATCHED / not affected
# 1 = VULNERABLE
# 2 = UNKNOWN / unable to determine
set -u
TARGET_TYPE=""
TARGET_VALUE=""
URL=""
VERSION=""
LIVE_NOTE=""
usage() {
echo "Usage: $0 (--container <name> | --path <dir>) [--url <https://host/explorer>]"
}
log() {
printf '%s\n' "$*" >&2
}
version_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && return 1
[ "$1" = "$2" ] && return 1
return 0
}
version_ge() {
[ "$1" = "$2" ] && return 0
! version_lt "$1" "$2"
}
extract_version_from_json() {
local file="$1"
grep -Eo '"version"[[:space:]]*:[[:space:]]*"[0-9]+\.[0-9]+\.[0-9]+"' "$file" 2>/dev/null | head -n1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+'
}
extract_version_from_container() {
local c="$1"
local img v p
img=$(docker inspect --format '{{.Config.Image}}' "$c" 2>/dev/null)
if [ -n "$img" ]; then
v=$(printf '%s' "$img" | sed -n 's/.*:\([0-9][0-9.]*\)$/\1/p' | head -n1)
if printf '%s' "$v" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+$'; then
printf '%s' "$v"
return 0
fi
fi
for p in /app/package.json /usr/src/app/package.json /workspace/package.json /graph-explorer/package.json; do
v=$(docker exec "$c" sh -c "test -f '$p' && cat '$p'" 2>/dev/null | grep -Eo '"version"[[:space:]]*:[[:space:]]*"[0-9]+\.[0-9]+\.[0-9]+"' | head -n1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+')
if [ -n "$v" ]; then
printf '%s' "$v"
return 0
fi
done
return 1
}
extract_version_from_path() {
local d="$1"
local p v
for p in "$d/package.json" "$d/app/package.json" "$d/graph-explorer/package.json"; do
if [ -f "$p" ]; then
v=$(extract_version_from_json "$p")
if [ -n "$v" ]; then
printf '%s' "$v"
return 0
fi
fi
done
return 1
}
probe_url() {
local raw="$1" scheme hostpath host http_code https_code http_url https_url
scheme=$(printf '%s' "$raw" | sed -n 's#^\(https\?\)://.*#\1#p')
hostpath=$(printf '%s' "$raw" | sed -n 's#^https\?://##p')
host=$(printf '%s' "$hostpath" | cut -d/ -f1)
if [ -z "$host" ]; then
LIVE_NOTE="live_check=invalid_url"
return
fi
http_url="http://$host/"
https_url="https://$host/"
http_code=$(curl -m 5 -ksS -o /dev/null -w '%{http_code}' "$http_url" 2>/dev/null || true)
https_code=$(curl -m 5 -ksS -o /dev/null -w '%{http_code}' "$https_url" 2>/dev/null || true)
if [ "$http_code" != "000" ] && [ "$https_code" = "000" ]; then
LIVE_NOTE="live_check=http_responds_https_fails"
elif [ "$http_code" != "000" ] && [ "$https_code" != "000" ]; then
LIVE_NOTE="live_check=http_and_https_respond"
elif [ "$http_code" = "000" ] && [ "$https_code" != "000" ]; then
LIVE_NOTE="live_check=https_only"
else
LIVE_NOTE="live_check=unreachable"
fi
}
while [ $# -gt 0 ]; do
case "$1" in
--container)
TARGET_TYPE="container"
TARGET_VALUE="${2:-}"
shift 2
;;
--path)
TARGET_TYPE="path"
TARGET_VALUE="${2:-}"
shift 2
;;
--url)
URL="${2:-}"
shift 2
;;
-h|--help)
usage
exit 2
;;
*)
log "Unknown argument: $1"
usage
exit 2
;;
esac
done
if [ -z "$TARGET_TYPE" ] || [ -z "$TARGET_VALUE" ]; then
usage
exit 2
fi
if [ "$TARGET_TYPE" = "container" ]; then
if ! command -v docker >/dev/null 2>&1; then
echo "UNKNOWN: docker not found"
exit 2
fi
VERSION=$(extract_version_from_container "$TARGET_VALUE" || true)
else
VERSION=$(extract_version_from_path "$TARGET_VALUE" || true)
fi
if [ -n "$URL" ]; then
probe_url "$URL"
fi
if [ -n "$VERSION" ]; then
if version_ge "$VERSION" "3.0.1"; then
echo "PATCHED: Graph Explorer version $VERSION ${LIVE_NOTE:+($LIVE_NOTE)}"
exit 0
fi
if version_ge "$VERSION" "1.1.0" && version_lt "$VERSION" "3.0.1"; then
echo "VULNERABLE: Graph Explorer version $VERSION is within affected range >=1.1.0,<3.0.1 ${LIVE_NOTE:+($LIVE_NOTE)}"
exit 1
fi
echo "PATCHED: Graph Explorer version $VERSION is outside the affected range ${LIVE_NOTE:+($LIVE_NOTE)}"
exit 0
fi
if [ "$LIVE_NOTE" = "live_check=http_responds_https_fails" ]; then
echo "UNKNOWN: could not determine version, but service appears to respond on HTTP while HTTPS fails ($LIVE_NOTE)"
exit 2
fi
echo "UNKNOWN: unable to determine Graph Explorer version ${LIVE_NOTE:+($LIVE_NOTE)}"
exit 2
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.