Original reporting by Threatpost (threatpost.com). Security researcher: Bob Diachenko.
What Happened
A publicly accessible Jenkins server owned by GE Aviation exposed sensitive internal assets — including plaintext passwords, source code, private keys, and global system configuration details — due to a DNS misconfiguration that made the server reachable from the open internet.
GE Aviation is a subsidiary of General Electric and one of the world’s leading commercial aircraft engine suppliers. The exposed Jenkins server reportedly contained a README file that listed all stored files along with notes about their sensitivity, effectively serving as an index for attackers.
How It Was Discovered
Security researcher Bob Diachenko discovered the open server after querying Shodan — a search engine that indexes internet-connected devices — to find how many Jenkins instances were publicly accessible. As of July 7, 2019, Diachenko reported finding 5,495 open and publicly available Jenkins instances in Shodan’s index.
After identifying the GE Aviation server in June 2019, Diachenko sent multiple notifications to the company. GE’s security team eventually responded and the server was taken down or secured. The duration for which the server remained publicly accessible was not disclosed.
Why Jenkins Servers Are a High-Value Target
Jenkins is a widely used open-source automation server written in Java, commonly deployed for continuous integration (CI) and continuous deployment (CD) pipelines. Because Jenkins sits at the center of the software delivery process, it routinely handles some of the most sensitive assets in a development environment.
- Source code — often the company’s core intellectual property
- API tokens and credentials — used to authenticate deployments to cloud services, registries, and databases
- Private keys — for SSH access, code signing, or TLS termination
- Configuration files — detailing internal network topology and service dependencies
- Database credentials — potentially granting direct access to production or staging data stores
“Jenkins is a service instance used by developers for integration and deployment. It is accessed via browser and can keep very sensitive information. Apart from source code itself, which is IP (Intellectual Property), it’s possible to dig out config files, API tokens, database credentials and lot more.”
— Bob Diachenko, security researcher
Root Cause: No Master Password and a DNS Misconfiguration
Two distinct failures contributed to this exposure:
- Disabled authentication. Jenkins supports authentication and authorization controls, but these must be explicitly configured and enforced. Diachenko noted that developers frequently disable password protection for convenience — for example, when working remotely on a project — leaving the Jenkins panel accessible to anyone who can reach the server’s URL.
- DNS misconfiguration. A misconfiguration in the server’s DNS records caused the internal Jenkins instance to resolve to a publicly routable IP address, exposing it to the internet rather than keeping it restricted to GE Aviation’s internal network.
Together, these two misconfigurations removed both layers of protection that should have kept the server private: network-level isolation and application-level authentication.
GE Aviation’s Response and Risk Classification
GE Aviation classified the incident as medium-risk, a characterisation that drew attention given the nature of the exposed data. The company stated it had found no evidence of unauthorised access, but reset all exposed credentials as a precautionary measure.
“Plaintext usernames and passwords were exposed on this server, but these credentials mapped to applications only accessible from our internal network, and no customer data, nor any significant GE data, was impacted. Furthermore, even if a malicious actor were to have acquired these credentials, they would also need access to our internal environment to exploit them.”
— GE Aviation statement
While GE Aviation’s argument that internal-network-only credentials limit direct exploitability has some merit, security practitioners generally consider plaintext credential exposure a high-severity finding regardless of where those credentials are subsequently used, because the credentials themselves can be leveraged in further attacks such as phishing, credential stuffing, or lateral movement if combined with other access paths.
Broader Context: A Pattern of Inadvertent Exposure
This incident was not isolated. Around the same period, several other organisations experienced similar inadvertent exposure events:
- Attunity (June 2019): Three publicly accessible cloud storage buckets belonging to the data management firm exposed more than a terabyte of data from Fortune 100 customers, including internal business documents and system passwords.
- HCL Technologies (May 2019): The IT services provider accidentally exposed passwords, sensitive project reports, and private customer and employee data on publicly accessible HCL subdomains.
- Facebook (April 2019): Hundreds of millions of Facebook user records were found in two separate publicly exposed third-party app datasets.
Each of these incidents shares a common thread: sensitive data placed in an internet-accessible location without adequate access controls, often as a result of misconfiguration rather than a sophisticated attack.
How to Prevent Jenkins Exposure
The GE Aviation incident is instructive for any team running Jenkins or similar CI/CD tooling. The following controls should be treated as baseline requirements:
- Enable authentication by default. Jenkins ships with security disabled in some older configurations. Always enable the built-in security realm or integrate with an identity provider (LDAP, SAML, OAuth) from the first deployment.
- Restrict network access. Jenkins should never be exposed directly to the public internet. Place it behind a VPN, restrict access by IP allowlist, or host it on an internal-only network segment.
- Audit DNS records regularly. DNS misconfigurations can inadvertently expose internal services. Use automated tooling to audit which hostnames resolve to public IP addresses and validate that this matches your intended exposure.
- Use credential management integrations. Avoid storing plaintext secrets in Jenkins configuration. Use the Jenkins Credentials Plugin, HashiCorp Vault, or a cloud-native secrets manager to inject credentials at runtime.
- Monitor with Shodan or similar tools. Proactively search for your own organisation’s exposed infrastructure. Many organisations now run periodic Shodan queries against their IP ranges and domain names as part of their attack surface management programme.
- Apply the principle of least privilege. Restrict which users and pipelines can access which credentials and environments. Role-based access control (RBAC) is available through Jenkins plugins such as the Role Strategy Plugin.
Key Takeaway
Sophisticated attacks are not always necessary to compromise sensitive corporate infrastructure. A single DNS misconfiguration combined with a missing authentication prompt was sufficient to expose an aircraft engine manufacturer’s internal credentials and source code to the entire internet. For DevOps teams, this underscores the importance of treating CI/CD infrastructure security with the same rigour applied to production systems — because in practice, your build server often holds the keys to your production environment.