Grouper bug GRP-6566 - GSH template security vulnerability
In Grouper v2.6.6 - v4.21.1 and v5.0.0 - v5.22.4 (depending on configuration) users can to execute GSH templates which they are not allowed to run. They can execute the templates from the User Interface or from Web Services. If you have grouper-ws.properties “ws.client.user.group.name” configured, then only those subjects can exploit the vulnerability via web service.
This vulnerability was discovered by Shilen Patel from Duke/Internet2 while developing Grouper.
or ask Chris Hyzer on slack for it. Note: ignore the PDFs in the zip file and refer to this wiki as the latest guidance instead.
- 1 Timeline
- 2 Who is impacted (high level)
- 3 What you should do now
- 4 Who is impacted (detailed)
- 5 If you are affected or unsure if you are affected
- 6 Remediation methods
- 7 Remediation method 1: disable/reconfigure the GSH templates
- 8 Remediation method 2: upgrade Grouper
- 9 Remediation method 3: patch the UI and WS container
- 10 Remediation method 4: edit the GSH template source
- 11 Remediation method 4a: edit the GSH template source (simple version)
- 12 Remediation method 4b: edit the GSH template source (generic version)
- 13 Determine if you have been compromised
- 14 Testing
- 15 Testing terminology
- 16 Testing description
- 17 Setup your environment
- 18 Run the test
- 19 Post steps
- 20 What is next
Timeline
2026/01/28 announced under embargo to the Grouper community, distributed patches for supported releases
2026/01/30 release v4.21.2 and v5.22.5 which fixed the vulnerability in supported releases
2026/02/07 public disclosure and CVE registration request
Who is impacted (high level)
Only GSH templates listed on this screen might be affected.
Potentially impacted: deployments that have enabled GSH templates
Not impacted: deployments that do not use GSH templates
GSH templates which are disabled are not affected
Built-in templates (e.g. to create app or policy group) are not affected.
What you should do now
If you have GSH templates and are unsure if you are affected:
Disable GSH templates immediately in all environments (prod/stage/dev) until you have confirmed you are not affected or have applied the remediation.
Who is impacted (detailed)
Certain configurations of GSH templates are affected. Unless any of the following configurations apply, the GSH template is affected. Some of your templates might be affected and some might not. Generally, you should patch or upgrade your container if you use GSH templates, but here are some specifics. Note: GSH scripts and GSH daemons are not GSH templates. Only GSH templates listed on the UI screen.
GSH templates which are disabled are not affected. Note: only GSH templates listed on this screen are affected. Built-in templates (e.g. to create app or policy group) are not affected.
GSH templates which are public are not affected
GSH templates which run as “Current user”, and do not use a Root session in the template source, are not affected if you determine it is ok for all users to run the template.
If you check security in your template source, it is not affected. Something like remediation 4a.
If you are running the template on a group or folder where only users who are allowed to run the template have any privileges on that group or that folder (or any descendant object in that folder) and you do not allow WS from no owner, then the template is not affected
If the GSH template is available from no owner from the WS, then anyone who can run WS can run the template
Template type “provisioner” is not affected (these are not common)
If you are affected or unsure if you are affected
You should disable your GSH templates immediately while you remediate the vulnerability. Keep track of which GSH templates were already disabled so you know which ones to enable after the remediation. After remediating, test to make sure the remediation works, and enable the GSH templates that you disabled. Then you can run a report to see if the vulnerability was exploited.
There is no single kill-switch. You can just go to the GSH template screen and disable each template. You could also import configs to disable templates (instructions not in this guide). If you change the config file and it does not disable the templates, then there is probably a database config overriding the config file, so just disable from the screen.
Using provisioners or other Grouper functions are not applicable, only GSH templates listed on the UI screen.
Remediation methods
Pick the best remediation method for your circumstances. You only need to perform one remediation method. The remediation method must be performed in all environments (dev/test/prod/etc). The same testing steps apply to all remediation methods.
Remediation method 1: disable/reconfigure the GSH templates
If it is not critical that you have your GSH templates enabled, then disable them. Do not enable any new templates until another remediation method is implemented.
You can test your templates and expect a response in the UI or WS of:
Template with config id '<templateConfigId>' is not enabled.
You could also reconfigure/recode your GSH templates to make them run as “Current user” if that is applicable for the specific template (unlikely).
Remediation method 2: upgrade Grouper
Grouper v4.21.2+ and v5.22.5+ fixes this vulnerability. These containers will be available when the vulnerability is announced to the public (since if we release the container the fix will be in git and will be known). Test the remediation with steps from the testing doc.
You can test your templates and expect a response in the UI or WS of:
currentUser with subject id '12345678' is not a member of 'group:can:run:template'.
Note: this message depends on the configuration of your template. E.g. if you are requiring wheel to run the template, you will get a message about not being a wheel group member.
Remediation method 3: patch the UI and WS container
This patch (from zip file above) can go in any Grouper component (Web Services, User Interface, Daemon, GSH), but is generally only required in the User Interface and Web Services. This patch will work in recent supported versions of Grouper only (from June 2025 forward).
There is a v4 patch for: v4.15.0 - v4.17.4.
There is a v4 patch for: v4.18.0 - v4.21.1.
There is a v5 patch for: v5.18.0 - v5.22.4.
If you are not running these versions and are affected, you should use a different remediation method and in the future upgrade more frequently to stay on supported versions of Grouper. If you really want a patch for a different version contact Chris Hyzer with your version.
Put the two patch files in your container (class files depend on version) and restart the container:
/opt/grouper/grouperWebapp/WEB- INF/classes/edu/internet2/
middleware/grouper/app/gsh/template/GshTemplateValidationService.class
/opt/grouper/grouperWebapp/WEB- INF/classes/edu/internet2/
middleware/grouper/app/gsh/template/GshTemplateValidationService$1.class
If you use slashRoot these can go in:
slashRoot/opt/grouper/grouperWebapp/…You can test your templates and expect a response in the UI or WS of:
currentUser with subject id '12345678' is not a member of 'group:can:run:template'.
Note: this message depends on the configuration of your template. E.g. if you are requiring wheel to run the template, you will get a message about not being a wheel group member.
Make a note (e.g. a comment in your Dockerfile) that when you upgrade grouper to v4.22.2+ or v5.22.5+ you MUST remove this patch.
Remediation method 4: edit the GSH template source
You can put a security check in each affected GSH template.
Determine your template version for each template you will remediate (used below)