Who is affected?

1. Users who host their own instance of shields and have set credentials for any of the eight services listed below.

Who is unaffected?

1. Users of the centralized service, https://shields.io/

   1. To avoid rate limiting problems, Shields has its own credentials for a few services (e.g. Symfony Insight). However the URLs for these services are hard-coded, so these credentials were not exposed.
   2. Shields policy is not to accept badges which require credentials to be passed in the query string, unless the credentials are read-only and can only be used for fetching status information.The main reason for this is so developers don't embed badge URLs which expose their credentials.

2. Users of the gh-badges npm package.

3. Self-hosting users who have not set credentials for any of the eight services listed below.

Impact

Users who host their own copy of Shields have the ability to configure credentials for several of the external services. Several of the badges provided by Shields allow users to specify the target URL/server of the upstream instance to use via a query parameter in the badge URL. This supports scenarios where your users may need badges from multiple upstream targets, for example if you have more than one Nexus server. When credentials are configured for one of these services, a request could trivially be crafted to exploit this feature, sending the credentials to any URL (and in most cases over either HTTP or HTTPS).

Credentials for the following services are affected:

• Bitbucket Server (but not Bitbucket Cloud)
• Drone
• Jenkins
• Jira
• Nexus
• npm
• Sonar
• TeamCity

Patches

The problem was fixed in PR #4729. Self-hosting users are recommended to upgrade immediately. We recommend revoking and regenerating any configured credentials for the affected services.

If you need time to do this, please remove the credentials from the configuration until then.

If you install from dockerhub, docker pull shieldsio/shields:next to update to the latest version.

When using credentials with services that accept arbitrary URLs, the authorized URLs must now be configured too, or else the credentials will not be set. See the documentation on configuring server secrets for more info. It is highly recommended to use https origins with valid SSL, to avoid the possibility of exposing your credentials, for example through DNS-based attacks.

One service, Jenkins, allows strict SSL checking to be disabled using a query parameter in the badge URL. This is supported for interoperability reasons (#1956). (Since the Jenkins service also supports HTTP to arbitrary hosts, credentials being sent over non-strict SSL may not represent a further vulnerability.) When using Jenkins, the disableStrictSsl option must now be enabled in configuration (otherwise those requests won't fire). When using Jenkins with credentials, the credentials will not be sent to disableStrictSsl requests, unless this is specifically enabled in configuration.

Workarounds

To remediate the vulnerability without upgrading, remove the configured secrets from the configuration. This will prevent them from being sent with any request.

We also recommend revoking and regenerating any configured credentials for the affected services.

For more information

If you have any questions or comments about this advisory:

• Post a comment in #4730
• Contact us on Discord; if necessary, we can set up a private channel with the maintainers and yourself