What Are The Security Risks of CI/CD Plugin Architectures?

Olga Bedrina

CI/CD pipelines are deeply embedded in modern software delivery. They interact with source code, secrets, cloud credentials, and production deployment targets. 

That position makes them an attractive target for attackers, and the plugin ecosystems that power many CI/CD platforms are an increasingly common point of entry.

This article explains how plugin-centric CI/CD architectures create security risk, what the vulnerability data actually shows, and how integrated platforms handle these risks differently. 

We’ll also be direct about TeamCity’s own security history, because we think that context matters when a CI/CD vendor writes about security.

What is a plugin-centric CI/CD architecture?

A plugin-centric CI/CD architecture is one where core platform functionality (integrations, triggers, build steps, notifications, and so on) is delivered through independently developed and maintained plugins rather than built into the platform itself.

Jenkins is the most widely used example. The Jenkins ecosystem includes thousands of community plugins, each maintained separately, with its own release cycle, security practices, and maintenance status.

This model offers significant flexibility. It’s also what introduces a specific class of security risk.

What are the security risks of CI/CD plugins?

When you rely on plugin-centric CI/CD architecture, you run the risk of introducing any of these systemic weaknesses:

• Decentralized development: Community-driven plugin development can result in inconsistent security standards and delayed patching of vulnerabilities. Simply put, you’re not in control of the plugin developer’s coding or security practices.
• Plugin abandonware: Some plugins may no longer be maintained, leaving known vulnerabilities unaddressed.
• Opaque dependencies: Complex interdependencies between plugins can create hidden attack surfaces that are difficult to monitor and secure.
• Excessive permissions: Plugins often require broad permissions, which increases the potential impact of a compromised or vulnerable plugin.

These weaknesses amplify the risk of security breaches and complicate efforts to maintain a secure CI/CD environment.

How many security vulnerabilities do Jenkins plugins have?

In 2025 alone, more than seventy security vulnerabilities have been found in Jenkins, most of them related to plugins. These range from CVE-2025-31722 in the Templating Engine plugin, which allows potential remote code execution due to insufficient sandboxing, to CVE-2025-53652 in the Git Parameter plugin, where misconfigured parameters can be abused for command injection.

Many of these vulnerabilities remain unpatched in live environments long after fixes are available. Last year, the Shadowserver Foundation detected over forty-five thousand internet-exposed Jenkins servers still vulnerable to CVE-2024-23897, indicating that attackers actively scan for and attempt to exploit outdated instances.

In some cases, the fallout has already been severe; the cause of the BORN Group’s supply chain compromise in 2022 was a vulnerable Jenkins plugin.

Has a CI/CD plugin vulnerability ever caused a real breach?

Unfortunately, yes. The 2022 BORN Group supply chain compromise was traced back to a vulnerable Jenkins plugin. Attackers were able to use the plugin as an entry point into the broader build environment.

This incident illustrates a risk pattern that’s also present in other dependency ecosystems like npm and PyPI: a compromised or abandoned plugin that’s automatically trusted and updated by a pipeline can silently inject malicious code into builds before anyone detects it. 

CI/CD plugins sit in a particularly sensitive position because the pipeline has direct access to repositories, secrets, and deployment targets.

What is CI/CD supply chain risk?

CI/CD supply chain risk refers to the possibility that a component in your build and delivery pipeline (a plugin, a dependency, a build image) is compromised in a way that affects the software that you ship to customers.

In plugin-heavy CI/CD environments, this risk is elevated because:

• Many plugins are maintained outside formal security oversight
• Abandoned projects can be quietly taken over by malicious actors
• Pipelines often automatically apply plugin updates without review
• The CI/CD system’s privileged access means a compromised plugin can affect everything downstream

The scale of CI/CD supply chain incidents is typically smaller than high-profile npm or PyPI cases, but the access that CI/CD systems have to production infrastructure makes the potential impact significant.

CI/CD supply chain risk refers to the possibility that a component in your build and delivery pipeline is compromised in a way that affects the software that you ship to customers.

How do CI/CD plugin vulnerabilities affect compliance?

If your CI/CD pipelines process or have access to personally identifiable information (which is true of most production systems) plugin security has regulatory implications.

GDPR, SOC 2, and HIPAA don’t prescribe specific CI/CD configurations, but they do require organizations to implement adequate security controls and maintain auditability over systems that handle protected data.

An unpatched plugin with known vulnerabilities, sitting inside a pipeline with access to production secrets, is a reasonable finding in a security audit.

Compliance teams and legal counsel are increasingly aware of CI/CD as a risk surface. It’s no longer a concern that can stay entirely within the engineering team.

How do integrated CI/CD platforms handle plugin security differently?

Integrated CI/CD platforms bundle core functionality natively rather than relying on external plugins for essential features. This changes the security model in a few specific ways:

Single vendor accountability. When a vulnerability is discovered in a core platform capability, there is one responsible party, one patch cycle, and one documented upgrade path.

You don’t need to track the release schedules of dozens of independent plugin maintainers.

Narrower external dependency surface. Fewer third-party plugins means fewer external dependencies to audit, monitor, and patch. The attack surface is smaller by design.

Native security capabilities. Secret management, access controls, and audit logging built into the platform are subject to the same security standards as the rest of the product. They don’t inherit the risk profile of a community-developed add-on.

More predictable patching. A critical vulnerability in a core platform feature gets a coordinated response. In plugin ecosystems, patch availability and adoption varies widely depending on who maintains each plugin.

Has TeamCity had security vulnerabilities?

Sadly, yes.

CVE-2024-27198 was a critical authentication bypass vulnerability in TeamCity that allowed unauthenticated remote code execution. It was rated 9.8 out of 10 on the CVSS scale and required urgent patching across all affected installations.

CVE-2023-42793 was another critical authentication bypass, also allowing remote code execution without authentication, which was actively exploited in the wild by threat actors including state-sponsored groups.

These were serious incidents. We’re not in a position to claim that integrated platforms are immune to vulnerabilities: we’re not, and our own history makes that clear. 

What we can say is that when these vulnerabilities were discovered, there was a single coordinated response, clear communication to users, and a defined upgrade path.

That’s the difference integrated platforms offer: not the absence of vulnerabilities, but a more accountable response when they occur.

How do I assess my current CI/CD platform’s security risk?

Regardless of which platform you use, these questions are worth working through periodically:

• How many plugins are active in your pipeline? Do you have a current inventory?
• When was each plugin last updated? Are any no longer actively maintained?
• What permissions do your plugins have? Are they scoped to what they actually need?
• How long does it take you to apply a critical security patch? Do you have a tested process?
• Who is responsible for plugin security in your organization? Is there clear ownership?
• Does your CI/CD configuration receive security review? Or only your application code?

These questions apply to any CI/CD environment. The answers tell you more about your actual risk posture than any platform comparison.

Is Jenkins insecure?

Not inherently. Jenkins is a mature, capable platform that thousands of engineering teams operate successfully and securely.

The security risks associated with Jenkins are largely a function of scale and the plugin model. When you have thousands of community plugins with varying maintenance quality, vulnerabilities are statistically inevitable.

Teams running Jenkins securely tend to do a few things consistently: they maintain a minimal plugin footprint, audit plugins regularly, apply patches promptly, and treat CI/CD configuration with the same rigor as application code. The operational discipline required is higher, but it’s achievable. 

The question isn’t whether Jenkins can be run securely. It’s whether your team has the capacity and processes to do so at your current scale.

When does it make sense to consider switching CI/CD platforms?

While the extensibility of many CI/CD platforms is convenient, it can create hidden vulnerabilities that disrupt operations, compromise sensitive data, or expose the organization to regulatory scrutiny. 

These risks affect IT teams, yes, but they also impact partners, customers, and the organization’s reputation. Leaders who understand these potential exposures can proactively reduce security risks, prevent disruptions, and ensure that CI/CD processes support both reliable operations and strategic growth.

An integrated CI/CD platform can help mitigate these risks. They reduce reliance on third-party plugins, provide native security and compliance capabilities, and offer vendor-managed updates with predictable patch cycles.

Switching CI/CD platforms is a significant undertaking and shouldn’t be driven by vendor comparisons alone. It makes sense to evaluate alternatives when:

• Your team is spending disproportionate time managing plugin updates and compatibility issues.
• You’ve had a security incident or near-miss traced to a plugin.
• Compliance or audit requirements are creating friction your current setup can’t easily address.
• Your plugin footprint has grown to the point where it’s difficult to audit or maintain.
• The operational overhead of maintaining your current platform is affecting delivery velocity.

If none of these apply, the case for switching is much weaker than any vendor will tell you.

Summary: what to take away from this

• Plugin-centric CI/CD architectures introduce structural security risks that are worth understanding clearly, regardless of which platform you use.
• Jenkins plugin vulnerabilities are frequent and well-documented; the patching gap between fix availability and actual deployment is a real operational challenge.
• CI/CD supply chain risk is real and follows the same patterns seen in other dependency ecosystems.
• Integrated platforms offer a different risk profile: not zero risk, but clearer accountability and more predictable patching
• TeamCity has had critical vulnerabilities of its own, including two severe authentication bypass issues in 2023 and 2024. 
• The most important security variable is usually your team’s processes and discipline, not your platform choice.

Subscribe to TeamCity Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!