## Summary
`IndexFile.remove()` and `Head.checkout()` forward `**kwargs` into `git rm` and `git checkout`
with no guard. Passing `--pathspec-from-file=<file>` **together with `--pathspec-file-nul`**
makes Git treat the whole file as a single NUL-delimited pathspec, and the unmatched-pathspec
error quotes it verbatim. GitPython surfaces that through `GitCommandError.stderr`, so the
entire contents of a caller-chosen file are returned to the caller in band.
This is the same primitive as Instance 2 of
[GHSA-3f7w-8rr8-f37f](https://github.com/advisories/GHSA-3f7w-8rr8-f37f) - `TagReference.create()`
with `-F`, arbitrary file read returned in band - at two sites that advisory assessed and
cleared.
## Prior art, and why I am filing rather than commenting
GHSA-3f7w-8rr8-f37f's sweep table lists these four sites with the assessment
*"`--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found"*:
| Call site | git command | that advisory's assessment |
|---|---|---|
| `IndexFile.remove()` | `rm` | `--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found |
| `IndexFile.move()` | `mv` | same |
| `HEAD.reset()` | `reset` | same |
| `HEAD.checkout()` | `checkout` | same |
That assessment is very nearly right, and I think that is why it held: with
`--pathspec-from-file` alone, Git splits on newlines and the error quotes only the **first
line**, which reads as an uninteresting partial. Adding `--pathspec-file-nul` - a sibling flag
of the same option, and the documented way to handle paths containing newlines - makes the
whole file one pathspec.
## Root cause
`git/index/base.py:991-1043`:
```python
def remove(self, items, working_tree=False, **kwargs):
...
removed_paths = self.repo.git.rm(args, paths, **kwargs).splitlines() # line 1043
```
`git/refs/head.py:237-268`:
```python
def checkout(self, force: bool = False, **kwargs: Any):
...
self.repo.git.checkout(self, **kwargs) # line 268
```
Neither has an `allow_unsafe_options` parameter or a `check_unsafe_options()` call.
## Proof of concept
```python
from git import Repo
from git.exc import GitCommandError
repo = Repo("/path/to/repo")
kw = dict(pathspec_from_file="/etc/passwd", pathspec_file_nul=True)
try:
repo.index.remove([], **kw) # or: repo.heads[0].checkout(**kw)
except GitCommandError as e:
print(e.stderr) # <- entire file contents
```
Observed on published 3.1.57, against a canary file holding three marked lines:
```
[PASS] IndexFile.remove() -> `git rm` returns ALL 3 canary lines in-band
stderr: 'fatal: pathspec 'LINE1-CANARY-4242
LINE2-SECRET-7777
LINE3-TAIL-9999
' did not match any files'
[PASS] Head.checkout() -> `git checkout` returns ALL 3 canary lines in-band
stderr: 'error: pathspec 'LINE1-CANARY-4242
LINE2-SECRET-7777
LINE3-TAIL-9999
' did not match any file(s) known to git'
[PASS] PRECISION: `git status` leaks 0/3 -- not every unguarded site discloses
[PASS] PRECISION: the GUARDED checkout-index leaks 0/3
```
The two precision controls are there so the result is about these sinks and not about the
canary being visible everywhere.
## Scope correction to the table above
Of the four sites cleared with that sentence, **two disclose and two do not**:
| Call site | disclosed? |
|---|---|
| `IndexFile.remove()` → `git rm` | **yes, full file** |
| `Head.checkout()` → `git checkout` | **yes, full file** |
| `HEAD.reset()` → `git reset` | no - `git reset` does not error on unmatched pathspecs |
| `IndexFile.move()` → `git mv` | no |
The two negatives are mentioned because "the dismissal was wrong" would overstate it: the
dismissal was wrong for half of what it covered.
A Cross-Site Request Forgery (CSRF) vulnerability exists in the yootheme.com Zoo extension for Joomla versions 1.0.0 through 4.1.64. The issue arises because the comment controller endpoint does not enforce Access Control List (ACL) checks, allowing unauthenticated users to modify tags without authorization. This vulnerability has a medium severity rating with a CVSS score of 6.9.
A stored cross-site scripting (XSS) vulnerability exists in the iCagenda extension for Joomla versions 4.0.8 through 4.0.12. The vulnerability occurs in the frontend 'Submit an Event' form, where the 'image' and 'file' fields are stored as raw strings without proper HTML attribute escaping. This allows authenticated users to inject malicious scripts that could be executed in the context of other users viewing the affected content.
In Splunk Enterprise Security versions below 8.6.1, a user who holds the ess_analyst Splunk Enterprise Security role could change User and Entity Behavior Analytics (UEBA) search macros that scheduled searches run with administrator permissions, allowing for access to all relevant data and system integrity through those searches. The vulnerability is possible because the UEBA app metadata grants analyst roles write access to search macros that should be writable only by administrator roles. For more information see Users and roles for Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/install/8.4/installation/users-and-roles-for-splunk-enterprise-security) and Roles and knowledge objects in UEBA for Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/administer/8.5/user-and-entity-behavior-analytics/roles-and-knowledge-objects-in-ueba-for-splunk-enterprise-security) in the Splunk documentation.
In Splunk Enterprise Security versions below 8.6.1, a user who holds a Splunk Enterprise Security role that contains the mc_investigation_read capability could inject Search Processing Language (SPL) through Analyst Queue search filters, allowing for access to all relevant data and system integrity available to the scheduled searches that run for that user. The vulnerability is possible because the Analyst Queue search filter handling does not validate filter field names before the fields are included in SPL searches. For more information see Users and roles for Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/install/8.4/installation/users-and-roles-for-splunk-enterprise-security), Manage analyst workflows using the analyst queue in Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/administer/8.4/mission-control/manage-analyst-workflows-using-the-analyst-queue-in-splunk-enterprise-security), and Overview of Mission Control in Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/user-guide/8.5/mission-control/overview-of-mission-control-in-splunk-enterprise-security) in the Splunk documentation.
In Splunk SOAR versions below 8.6.0, a user who holds the "Automation Engineer" Splunk SOAR role could run arbitrary Structured Query Language (SQL) statements against the Splunk SOAR database through custom list retrieval in a playbook, allowing for create, read, update, and delete operations on all relevant data stored in the Splunk SOAR database. The SQL injection is possible because Splunk SOAR builds the custom list database lookup with the supplied list name instead of a bound SQL value. For more information see Manage roles and permissions in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) and Create custom lists for use in Splunk SOAR playbook comparisons (https://help.splunk.com/en/splunk-soar/soar-cloud/build-playbooks/manage-playbooks-and-playbook-settings/create-custom-lists-for-use-in-splunk-soar-cloud-playbook-comparisons) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could create or modify a scripted lookup through generic configuration endpoints and run an installed lookup script with the permissions of the user account running Splunk Enterprise, which could allow for access to all relevant data and affect system integrity and availability. The vulnerability is possible because the generic transforms configuration endpoints do not enforce the capabilities required to create or edit external lookup definitions. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) and limits.conf (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/configuration-file-reference/10.4.2-configuration-file-reference/limits.conf) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the schedule_search capability could configure Portable Document Format (PDF) attachments in the email alert action workflow. When the email alert action runs, it could execute arbitrary Search Processing Language (SPL) commands with system-level privileges, expose all relevant data, and affect system integrity and availability on the search head. The vulnerability is possible because the search scheduler passes a system-level authentication context rather than the action owner context to the email alert action when it renders PDF attachments. For more information see alert_actions.conf (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/configuration-file-reference/10.4.0-configuration-file-reference/alert_actions.conf) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has access to a trusted distributed search private key could forge an administrative session token, access all relevant data, affect system integrity, and disrupt service availability. The vulnerability is possible because the distributed search authentication token endpoint does not require a signed request to identify a configured search peer, allowing the request to fall back to shared local key material. For more information see About distributed search (https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/10.4/overview-of-distributed-search/about-distributed-search) and authentication.conf (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/configuration-file-reference/10.4.2-configuration-file-reference/authentication.conf) in Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could inject Search Processing Language (SPL) into saved-search dispatch requests. This could allow for unauthorized access to all relevant data and affect system integrity within Splunk Enterprise. The vulnerability is possible because Splunk Enterprise does not correctly validate caller-supplied time values before using them in saved-search dispatch. For more information see Search endpoint descriptions (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.2/search-endpoints/search-endpoint-descriptions) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a dashboard. When another authenticated user exports the dashboard as a Portable Document Format (PDF) file, Splunk Enterprise runs the injected SPL using the permissions of that user. The injected SPL could access or modify data available to that user. The vulnerability is possible because Splunk Web does not sufficiently validate dashboard content before processing PDF exports. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Generate PDFs of your reports and dashboards (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/9.4/report-management/generate-pdfs-of-your-reports-and-dashboards) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a low-privileged user that does not hold the fsh_manage capability could perform Remote Code Execution through Federated Search bundle selection. This could allow for access to all relevant data and affect system integrity and availability. The vulnerability is possible because the Federated Search dispatch flow accepts caller-controlled bundle selection without enforcing the capability that manages federated providers and indexes. For more information see Security models for Federated Search for Splunk (https://help.splunk.com/en/splunk-enterprise/search/federated-search/10.4/run-federated-searches-across-other-splunk-deployments/service-accounts-and-security-for-federated-search-for-splunk/security-models-for-federated-search-for-splunk) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could inject arbitrary Search Processing Language (SPL) into requests that search for events near a selected event. This could allow for unauthorized search execution. The vulnerability is possible because Splunk Web does not consistently escape caller-supplied values when it builds SPL for nearby-event searches, and embedded report access accepts those requests without the expected authorization check. For more information see Use time to find nearby events (https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.2/specify-time-ranges/use-time-to-find-nearby-events) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could move files that the user account running Splunk Enterprise can read into a lookup that the user controls. The user could then access all relevant data and affect system integrity and availability on the search head. The vulnerability is possible because the lookup configuration endpoint does not resolve lookup source paths before checking whether they stay inside the allowed lookup staging area. For more information see About lookups (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.4/use-lookups-in-splunk-web/about-lookups) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "user" Splunk role could craft a Dashboard Studio dashboard that runs attacker-controlled Search Processing Language (SPL) for another authenticated user. The attacker-controlled SPL could access all relevant data and affect system integrity and availability. The vulnerability is possible because Dashboard Studio does not consistently enforce the expected app-visibility authorization boundary before dashboard search query options reach search dispatch. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "user" Splunk role should not be able to exploit the vulnerability at will. For more information see Create search-based visualizations with ds.search (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/dashboard-studio/10.4/use-data-sources/create-search-based-visualizations-with-ds.search) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could bypass Search Processing Language (SPL) safeguards for risky commands through the Job Details dashboard. The injected SPL could run using the permissions of an authenticated user who opens a crafted Job Details dashboard link. This could allow access to all relevant data and affect system integrity within those permissions. The vulnerability is possible because the Job Details dashboard does not correctly neutralize a caller-supplied search identifier before placing it into SPL searches. The vulnerability requires the attacker to phish the user by tricking them into opening the crafted link. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see About jobs and job management (https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.4/manage-jobs/about-jobs-and-job-management) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could perform Remote Code Execution (RCE) by uploading a malicious knowledge bundle and causing it to be used by distributed search, which can allow for access to all relevant data and affect system integrity and availability. The vulnerability is possible because the Representational State Transfer (REST) API endpoint for knowledge bundle upload does not require the high-privilege capability edit_dist_peer, and distributed search accepts caller-supplied knowledge bundle selections from users who do not hold that capability. For more information see What search heads send to search peers (https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/9.2/knowledge-bundle-replication/what-search-heads-send-to-search-peers), About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.0/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access), Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.1/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities), and Using the REST API reference (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.4/introduction/using-the-rest-api-reference) in the Splunk documentation.
In Splunk Enterprise versions below 10.4.1, 10.2.5, 10.0.9, and 9.4.14, an unauthenticated user who can reach the Splunk management port could store a Search Processing Language (SPL) pipeline that runs when an administrator opens the Add Data forwarder workflow. The SPL pipeline could access all relevant data, affect system integrity, and affect availability of the Splunk platform instance. The SPL injection is possible because Deployment Server client identifiers are placed into dispatched searches without neutralizing special characters. Successful exploitation requires an administrator to open the affected Add Data forwarder workflow after the unauthenticated user registers a crafted Deployment Server client identity. For more information see Forward data (https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.2/how-to-get-data-into-your-splunk-deployment/forward-data) and About agent management (https://help.splunk.com/en/splunk-enterprise/administer/update-your-deployment/10.4/agent-management/about-agent-management) in the Splunk documentation.