Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Some Groovy annotations can trigger code during compilation, before Jenkins applies the runtime checks of its Groovy Sandbox. That creates a security boundary problem: transformation code may run before the sandbox can check its operations. Jenkins has fixed several specific annotation pathways, but that does not mean every Groovy annotation is unsafe—or that a fix for one pathway covers them all.

Why compile-time annotations can get ahead of the sandbox

Groovy scripts pass through compilation before they execute. An annotation can ask Groovy to transform code during that earlier phase—for example, by generating code or invoking a transformation class. If that transformation runs before sandbox protections are applied, its behavior may not be mediated by the runtime checks that protect the script afterward.

Jenkins describes the Groovy Sandbox as checking operations such as method calls, object construction, and field access as a script runs. Operations that are not approved halt execution. Those checks are important, but they are not a substitute for compiler configuration that prevents unsafe transformation behavior from running during compilation. See the Jenkins Script Security plugin documentation for the sandbox and secure compiler configuration.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The precise risk depends on the annotation pathway, the Script Security Plugin version, and, in some cases, what is available on the classpath. Jenkins advisories describe several distinct cases; they do not establish that every annotation or every AST transformation is exploitable.

Which annotation cases Jenkins has documented

September 2026: transformation classes and builder strategies

The Jenkins Security Team’s September 16, 2026 advisory identifies Script Security Plugin version 1415.v9a_f9b_3a_c253d and earlier as affected by two compile-time annotation issues relevant here.

  • @GroovyASTTransformationClass: A script could associate an annotation type it declares with an arbitrary AST transformation. Groovy could run that transformation during compilation, before the sandbox applied. The advisory says version 1422.v06869826dd9b_ rejects this annotation during sandbox compilation, before Groovy can resolve or execute the referenced script.
  • @Builder: Groovy can generate builder code during compilation using a strategy class named by the annotation. In affected versions, arbitrary strategies were not rejected and could be instantiated before the sandbox applied. Version 1422.v06869826dd9b_ rejects builder strategies other than Groovy-provided strategies during sandbox compilation. The advisory notes that star imports do not work for the built-in strategies; use a fully qualified name or a single-class import instead.

The same September advisory covers other Script Security issues, including a collection-cast sandbox bypass and a classpath approval bypass. Those are separate vulnerabilities, not compile-time annotation cases, so they should not be treated as evidence about annotation behavior.

June 2026: an extensions member on transformation annotations

The Jenkins Security Team’s June 24, 2026 advisory says Script Security Plugin 1402.v94c9ce464861 and earlier did not reject Groovy AST transformation annotations such as @CompileStatic and @TypeChecked when they carried an extensions member. That member could cause a script to be loaded from the classpath and executed during compilation, before the sandbox applied.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The advisory identifies 1402.1405.vc96e74964250 as the fix: sandbox compilation rejects any annotation carrying an extensions member. It rates the issue High but says successful exploitation is considered very unlikely because a suitable Groovy script must be present on the evaluating component’s classpath. The security team reported it could not identify such a dangerous Groovy source file in Jenkins core or plugins. This qualification applies to this particular issue; it should not be generalized to the other annotation cases.

Earlier @Grab cases

Jenkins’ January 8, 2019 advisory described sandbox bypasses during compilation involving AST-transforming annotations such as @Grab. The announced fixes prohibited known unsafe AST transformations in sandboxed scripts. A January 28 follow-up recorded a further issue affecting a validation endpoint missed by the initial fix; affected validation endpoints were changed to use safe compiler configurations.

In 2020, Jenkins documented another incomplete-fix issue involving @Grab on imports or inside other annotations. Script Security Plugin 1.70 disallowed known unsafe transformations in those positions. This history shows why the protection must cover the relevant compiler pathways, not just one visible use of an annotation.

How sandboxing, approval, and compiler restrictions differ

Control When it acts What it controls What it does not replace
Groovy Sandbox As script operations run Method calls, object construction, and field access against approved operations Safe compiler configuration for transformations that can run before script execution
Script Approval Before an unapproved script or signature is allowed Approval of whole scripts or permission for additional method signatures Sandbox checks for operations in sandboxed scripts
Safe compiler configuration or advisory-specific annotation rejection During sandbox compilation Known unsafe transformation or annotation pathways Other fixes not covered by the specific compiler restriction

Jenkins’ In-process Script Approval guidance describes the administrative approval process separately from sandboxing. Pipeline scripts generally run in the sandbox by default, including administrator-authored Pipelines, according to Jenkins’ administration guidance. Approval and sandboxing therefore answer different questions: whether a script or signature is permitted, and whether operations in a sandboxed script are allowed.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What Jenkins administrators should do

  1. Check the installed Script Security Plugin version. Use the plugin manager or your normal plugin inventory process, then compare the version with the affected and fixed versions in the advisory that matches the annotation pathway. The September 2026 cases name 1422.v06869826dd9b_ as the fix; the June extensions-member issue names 1402.1405.vc96e74964250.
  2. Update to a version that fixes the applicable advisory. Do not assume that resolving one case proves another is fixed. Review the current September advisory and June advisory against your installed version.
  3. Keep sandboxing enabled where it is appropriate. A compiler-phase issue is not a reason to treat runtime sandboxing as ineffective; it is a reason to maintain both runtime controls and the compiler protections that address the relevant transformation path.
  4. Review scripts and plugin code that introduce AST transformations. Jenkins developer guidance cautions plugin authors about AST transformations, particularly global transformations discovered through META-INF/services. A blocklist can prevent known unsafe transformations, but that guidance is not a guarantee that every transformation or plugin arrangement is safe. See Jenkins’ miscellaneous API usage recommendations.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Why @NonCPS is not a workaround

Pipeline: Groovy uses Groovy CPS transformation during compilation. Its documentation explains that @NonCPS changes CPS transformation behavior for designated methods, but those methods remain subject to sandbox security checks. It is not a way to bypass sandboxing or to make an unsafe compile-time annotation safe. See the Pipeline: Groovy plugin documentation.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.