Port 8086 – InfluxDB (Time-Series Database HTTP API)

Port 8086 is the default port for the InfluxDB HTTP API — the endpoint that InfluxDB, a popular open-source time-series database, uses to read and write data. Metrics pipelines, monitoring stacks, and IoT platforms push their measurements here over HTTP and query them back with InfluxQL against paths like /write, /query, and /ping. The catch is that InfluxDB 1.x ships with authentication disabled by default: unless an operator explicitly turned it on, an open port 8086 means anyone who can reach it can list every database, read the data, and drop measurements — no credentials required. Because the databases behind it usually hold infrastructure telemetry, application metrics, and sensor readings, an exposed 8086 is both an easy data-exfiltration target and a way to quietly wipe monitoring history.

Why It’s Open

Port 8086 is open because something is storing or querying time-series data. The classic pattern is a TICK / metrics stack: Telegraf, collectd, or a custom agent writes samples into InfluxDB over 8086, and a dashboard — often Grafana — reads them back to draw graphs. It is the backbone of a huge number of self-hosted monitoring, DevOps, and IoT deployments, so on a server that does any kind of metrics collection, 8086 answering is expected.

The reason it so often ends up exposed is a combination of defaults and convenience:

• InfluxDB 1.x binds the HTTP API to 0.0.0.0:8086 and runs with [http] auth-enabled = false out of the box. Getting data flowing “just works” without configuring users or tokens, so many deployments never turn auth on.
• Remote agents and remote dashboards need to reach the database, so operators open 8086 to the network — and “the network” frequently means the internet once a cloud security group is left wide.
• The separate admin web UI historically lived on port 8083 (removed in InfluxDB 1.3), while the data API stayed on 8086, so 8086 is the port that actually matters for reading and writing data.

InfluxDB 2.x changed the model: it merged the UI and API onto 8086, requires an initial setup, and enforces token-based authentication (operator, all-access, and scoped tokens) by default. That closes the auth-off-by-default gap — but a large installed base of 1.x is still running, and a 2.x instance is only as safe as the tokens protecting it.

Common Risks

• Authentication disabled by default (1.x). With auth-enabled = false, the HTTP API is fully open: SHOW DATABASES, SELECT, DROP, and /write all work unauthenticated to anyone who can reach 8086. It is the same open-by-default trap that makes Redis on 6379 and the Elasticsearch REST API on 9200 such common breaches — a data store reachable from the network with no credentials in front of it.
• Data exfiltration. Time-series databases are rarely thought of as “sensitive,” but they leak a map of the estate — hostnames, service names, request rates, error counts, business KPIs, and IoT/sensor readings — handing an attacker detailed reconnaissance for free.
• Data destruction / integrity loss. DROP DATABASE, DROP MEASUREMENT, and DELETE are just HTTP requests. An unauthenticated writer can wipe monitoring history, blinding the very dashboards used to detect an intrusion, or poison the data to hide activity.
• JWT authentication bypass (CVE-2019-20933). Even where auth is enabled, 1.x builds before 1.7.6 accept a JWT signed with an empty shared secret — forge a token for any username and you are authenticated (see CVEs below).
• Weak or absent tokens (2.x). A 2.x instance published to the internet with a guessable or leaked all-access token is as exposed as an unauthenticated 1.x box.
• No transport encryption by default. HTTPS is off unless configured, so credentials/tokens and query results travel in cleartext where TLS was never enabled.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Confirm the service and version first, then check whether authentication is actually enforced — on 1.x it usually is not.

Detect the service and version

nmap -sV -p 8086 <target>

Check the API is alive (the /ping endpoint returns the version header)

curl -si "http://<target>:8086/ping"

/ping returns 204 No Content with an X-Influxdb-Version header, which fingerprints the exact build so you can map it to known CVEs.

Test for unauthenticated access — list the databases

curl -G "http://<target>:8086/query" --data-urlencode "q=SHOW DATABASES"

If this returns a JSON list of databases without credentials, authentication is disabled. Follow up by enumerating measurements and reading data:

curl -G "http://<target>:8086/query" --data-urlencode "db=<database>" --data-urlencode "q=SHOW MEASUREMENTS"
curl -G "http://<target>:8086/query" --data-urlencode "db=<database>" --data-urlencode "q=SELECT * FROM <measurement> LIMIT 10"

Interactive access with the InfluxDB CLI

influx -host <target> -port 8086
# then, at the prompt:
> SHOW DATABASES

Enumerate with Metasploit

The framework’s InfluxDB scanner probes the API and tries the classic root:root default:

msfconsole -q
use auxiliary/scanner/http/influxdb_enum
set RHOSTS <target>
run

JWT authentication bypass (CVE-2019-20933)

Against an auth-enabled 1.x build older than 1.7.6, the public PoC forges a JWT with an empty shared secret to reach the API as any user. There is no dedicated Metasploit module for this; use the widely referenced LorenzoTullini/InfluxDB-Exploit-CVE-2019-20933 tool, which bruteforces the username and drops into a query shell.

Record every open port 8086, the exact X-Influxdb-Version, whether auth was enforced, and any database contents you could read, so the evidence lands in the pentest report instead of a scratch terminal you will lose.

What to Look For

Known CVEs and Exploits

There is no generic “port 8086” CVE — by far the dominant risk on this port is a design default, not a code bug: InfluxDB 1.x ships with authentication turned off, so an exposed 8086 is typically wide open to unauthenticated read/write over the HTTP API. The one high-impact named vulnerability that matters here is the JWT bypass:

• CVE-2019-20933 — Authentication bypass in InfluxDB before 1.7.6. The authenticate function in services/httpd/handler.go accepts a JWT token whose SharedSecret (shared secret) is empty, so an attacker can forge a valid token for any username and reach the API as an authenticated user — even when auth is enabled. CVSS 3.1 9.8 (CRITICAL). Public PoC: LorenzoTullini/InfluxDB-Exploit-CVE-2019-20933 (checks the target, bruteforces the username, and returns a query shell). There is no official Metasploit module for this CVE — the framework only ships the auxiliary/scanner/http/influxdb_enum reconnaissance scanner.

Verify before you cite. CVE-2019-12210 is sometimes floated as an “InfluxDB” issue — it is not. NVD scopes it to Yubico pam-u2f 1.0.7 (a file-descriptor leak), with nothing to do with InfluxDB or port 8086, so it does not belong on this page. Always confirm a CVE’s product against its NVD record before trusting it. The honest bottom line for 8086 is that the primary exposure is auth-off-by-default plus CVE-2019-20933 on unpatched 1.x builds; harden those two and the port is far less interesting to an attacker.

Mitigation

• Enable authentication (1.x). Set [http] auth-enabled = true, create an admin user, and require credentials on every request. This single change closes the default open-door problem.
• Upgrade past 1.7.6 (ideally to a current 1.x or InfluxDB 2.x) to remove the CVE-2019-20933 JWT bypass, and on 2.x use scoped tokens rather than a single all-access token.
• Bind to localhost or a private interface. If only local agents write to InfluxDB, set the HTTP bind address to 127.0.0.1:8086 instead of 0.0.0.0, or restrict it to a management subnet.
• Firewall TCP/8086 to the specific agents and dashboard hosts that need it, and audit cloud security groups and container port maps for an accidental 0.0.0.0:8086.
• Enable TLS on the HTTP API so tokens and query results are not sent in cleartext, and front the API with a reverse proxy where you need extra authentication or rate limiting.
• Least-privilege database users. Give writers write-only scopes and dashboards read-only scopes so a single leaked credential cannot DROP your data.
• Close it if nothing needs it, then rescan (nmap -p 8086 <target>) to confirm the port is no longer reachable from untrusted networks.

Real-World Example

InfluxDB’s auth-off-by-default posture has repeatedly turned Shodan into a menu of open metrics databases. Because 1.x binds 8086 to all interfaces with auth-enabled = false, thousands of instances have been indexed answering SHOW DATABASES to anyone who asks — no credentials, no exploit, just an HTTP request. Security researchers demonstrating CVE-2019-20933 showed the sharper edge of the same problem: even operators who did enable authentication on a 1.x build older than 1.7.6 were bypassable, because the server accepted a JWT signed with an empty shared secret. The published PoC simply forges a token for a guessed username and lands in a query shell with full read/write. It is the port-8086 lesson in miniature — the database looks like harmless plumbing, but an open API on it hands over the organisation’s telemetry and lets an attacker rewrite or erase the very history that would have revealed them. Enabling auth and patching past 1.7.6 removes both edges at once.

FAQ

What is port 8086 used for?

Port 8086 is the default port for InfluxDB’s HTTP API — the endpoint clients use to write and query time-series data. Monitoring agents (Telegraf, collectd), IoT platforms, and dashboards such as Grafana talk to InfluxDB over 8086 using paths like /write, /query, and /ping. In InfluxDB 2.x the built-in web UI is served on 8086 as well.

Is port 8086 dangerous to leave open?

It can be. InfluxDB 1.x ships with authentication disabled by default, so an internet-reachable 8086 typically lets anyone list databases, read every measurement, and even drop data with no credentials. Do not expose 8086 without enabling authentication (or, on 2.x, protecting it with strong tokens) and firewalling it to the hosts that actually need it.

Does InfluxDB require a password by default?

No — not in 1.x. Authentication is off unless an operator sets [http] auth-enabled = true and creates users, which is exactly why so many 1.x instances are wide open. InfluxDB 2.x is different: it enforces token-based authentication from initial setup, so a default 2.x install is not unauthenticated the way a default 1.x install is.

What is CVE-2019-20933?

It is a critical (CVSS 9.8) authentication bypass in InfluxDB before 1.7.6. The server accepts a JWT whose shared secret is empty, so an attacker can forge a valid token for any username and access the API as an authenticated user — even when authentication is enabled. Upgrading past 1.7.6 fixes it; a public PoC exists that bruteforces the username and returns a query shell.

How do I check whether my InfluxDB on 8086 is exposed?

Run curl -G "http://<host>:8086/query" --data-urlencode "q=SHOW DATABASES". If it returns a list of databases without credentials, authentication is disabled and the instance is open. Also check the version with curl -si http://<host>:8086/ping (read the X-Influxdb-Version header) — anything below 1.7.6 is additionally vulnerable to the CVE-2019-20933 bypass.

How do I secure or close port 8086?

Enable authentication (1.x) or use scoped tokens (2.x), upgrade past 1.7.6, bind the API to localhost or a private interface, enable TLS, and firewall TCP/8086 to the agents and dashboards that need it. If nothing legitimately needs remote access, restrict it to localhost and confirm with nmap -p 8086 <host> that the port is no longer reachable.

TL;DR

• Service: InfluxDB HTTP API (time-series database for metrics, monitoring, and IoT)
• Default port: 8086/TCP (the data read/write API; the legacy admin UI was on 8083)
• Biggest risk: authentication is disabled by default in InfluxDB 1.x, so an exposed 8086 lets anyone query, exfiltrate, or DROP time-series data over the HTTP API — plus the CVE-2019-20933 JWT bypass on builds before 1.7.6
• Mitigation: enable auth (1.x) or protect tokens (2.x), upgrade past 1.7.6, bind to localhost/private, enable TLS, and firewall 8086 to known agents and dashboards — capture findings in the pentest report