The Adaptavist Group LogoDocumentation

Secure Shell Hardening Breaking Change for Project and Repository Scripts

A security vulnerability has been found in ScriptRunner for Bitbucket Data Center. It affects all versions before 10.19.0, 9.45.0, and 8.70.0.

ScriptRunner for Jira and ScriptRunner for Confluence aren't affected.

The vulnerability has a CVSS score of 9.9 and is rated Critical. It has no CVE number because it isn't related to a public CVE.

To fix it, we've strengthened the secure shell, the restricted environment that project and repository scripts run in. This hardening is turned on automatically when you upgrade. Most scripts aren't affected, but some may need updating. This page explains what's changed, how to check your scripts before you upgrade, and what to do if you can't upgrade straight away.

Please upgrade to the latest ScriptRunner version available for your Bitbucket instance as soon as possible.

What happened?

We confirmed a vulnerability during a security review, following a report submitted to us.

At the time of writing, we have no indication that this vulnerability has been exploited.

What's changed?

The hardening applies to scripts that project and repository administrators configure, including pre-receive hooks, merge checks, and conditions.

Scripts configured by system administrators, such as global scripts, aren't affected. This change also doesn't affect ScriptRunner for Jira or ScriptRunner for Confluence.

Most everyday scripting, including the Bitbucket hook API, keeps working as before.

A small number of less common scripting techniques are now restricted. If a script uses one of these, it fails to compile when it's saved or run, and the error message explains what was blocked.

If you'd like more information about which scripting patterns have changed, please contact our support team.

What do I need to do?

Upgrade to the latest version of ScriptRunner available for your Bitbucket instance. Hardening is on by default, so no extra configuration is needed.

If you'd like to check which of your scripts might be affected before hardening takes effect, set up report mode before you upgrade. See Before you upgrade: check your scripts.

Available versions:

  • ScriptRunner 10.19.0 compatible with Bitbucket 10.0.0 - 10.5.1
  • ScriptRunner 9.45.0 compatible with Bitbucket 9.0.0 - 9.6.5
  • ScriptRunner 8.70.0 compatible with Bitbucket 8.0.0 - 8.19.29

Learn how to update your version of ScriptRunner for Bitbucket using this guide.

If you have an Atlassian partner, you can reach out to them for help with this upgrade. If you don't have an Atlassian partner, you can reach out to our support team.

Before you upgrade: check your scripts

Most scripts will work as expected after the upgrade, but if you'd like to be sure, you can set hardening to report mode before upgrading. In report mode, restricted operations are still allowed to run, and each one is written to the Bitbucket log. You can then use the log to find and update affected scripts.

Hardening is controlled by JVM system properties, which are read once when ScriptRunner starts. Because hardening is on by default, you need to set report mode before you upgrade for it to apply from the start.

CAUTION: Report mode doesn't protect you from the vulnerability.

It gives you visibility of what hardening would block, but your instance stays exposed while it's set. We recommend keeping report mode in place for as short a time as possible, and turning on Admin-Only Project and Repository Script Access while you review your scripts.

Set report mode

You need administrator access to the Bitbucket server and permission to restart it.

  1. Stop Bitbucket.
  2. Add the following JVM system property to JVM_SUPPORT_RECOMMENDED_ARGS:
    -Dadaptavist.scriptrunner.bitbucket.sandbox.hardening=report

    If JVM_SUPPORT_RECOMMENDED_ARGS already has values, add this one inside the same quotes, separated by a space.

    Where you set this depends on how you run Bitbucket. See Atlassian's documentation:

    For Docker, pass the property in the JVM_SUPPORT_RECOMMENDED_ARGS environment variable when you start the container.

  3. Start Bitbucket.
  4. Upgrade ScriptRunner.

If you run a clustered deployment, set the same property on every node, and start each node before you upgrade ScriptRunner.

Review the logs

In report mode, each operation that hardening would block is written to the Bitbucket application log:

  • Linux and macOS: <Bitbucket home directory>/log/atlassian-bitbucket.log
  • Windows: <Bitbucket home directory>\log\atlassian-bitbucket.log

Each entry is a WARN line containing SR-SANDBOX-HARDENING would block, followed by the name of the affected script and the line number.

Entries appear as your scripts are saved or run, so allow time for your usual repository activity before relying on the results.

To find all report-mode entries on Linux or macOS:

grep "SR-SANDBOX-HARDENING" "<Bitbucket home directory>/log/atlassian-bitbucket.log"

To list each affected script once:

grep "SR-SANDBOX-HARDENING" "<Bitbucket home directory>/log/atlassian-bitbucket.log" | grep -o "script=[^ ]*" | sort -u

On Windows, you can use PowerShell:

Select-String -Path "<Bitbucket home directory>\log\atlassian-bitbucket.log" -Pattern "SR-SANDBOX-HARDENING"

Older entries may be in rotated log files in the same log directory.

Update affected scripts

For each script named in the log, update it so it no longer uses the restricted operation. If you're not sure how to rewrite a script or would like more detail on what's changed, please contact our support team.

Switch back to enforce

When you've updated your scripts, change the property to enforce:

JVM_SUPPORT_RECOMMENDED_ARGS="-Dadaptavist.scriptrunner.bitbucket.sandbox.hardening=enforce"

Then restart Bitbucket. In a clustered deployment, apply the same change on every node.

You can also remove the property entirely, since enforce is the default.

If hardening blocks a script you need

If you can't update a script to work with hardening, there are two options. We recommend trying them in this order.

Allow a specific exception

If one of your scripts genuinely needs an operation that hardening blocks, it may be possible to allow that specific operation while keeping all other hardening in place.

CAUTION: Allowing an exception re-opens part of the risk this fix closes.

We recommend updating your scripts wherever possible, and only allowing exceptions you're confident you need.

To determine whether an exception is appropriate for your setup, please contact our support team. It helps to include the relevant report-mode log entries and the names of the affected scripts, so we can advise on the safest option.

Turn hardening off

If required, you can turn hardening off completely by setting the property to off:

JVM_SUPPORT_RECOMMENDED_ARGS="-Dadaptavist.scriptrunner.bitbucket.sandbox.hardening=off"

Follow the steps in Set report mode, using off instead of report.

Warning: With hardening off, your instance is fully exposed to this vulnerability.

If you turn hardening off, we strongly recommend turning on Admin-Only Project and Repository Script Access, and contacting our support team so we can help you get hardening back on.

What if I can't upgrade?

If you can't upgrade straight away, we recommend turning on Admin-Only Project and Repository Script Access. This removes ScriptRunner scripting access for project and repository administrators, so only system administrators can configure scripts until you upgrade. For full protection, don't give any groups access through this setting.

If this isn't workable for your setup, or you don't expect to be able to upgrade, please reach out to our support team.

If you have any other questions or need further support, please raise a ticket here.

Search documentation

Start typing to search the docs.