Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
|
Description: Summary
A security vulnerability has been identified in the GitHub CLI that could leak authentication tokens when cloning repositories containing git submodules hosted outside of GitHub.com and ghe.com.
Details
This vulnerability stems from several gh commands used to clone a repository with submodules from a non-GitHub host including gh repo clone, gh repo fork, gh pr checkout. These GitHub CLI commands invoke git with instructions to retrieve authentication tokens using the credential.helper configuration variable for any host encountered.
Prior to 2.63.0, hosts other than GitHub.com and ghe.com are treated as GitHub Enterprise Server hosts and have tokens sourced from the following environment variables before falling back to host-specific tokens stored within system-specific secured storage:
GITHUB_ENTERPRISE_TOKEN
GH_ENTERPRISE_TOKEN
GITHUB_TOKEN when CODESPACES environment variable is set
The result being git sending authentication tokens when cloning submodules.
In 2.63.0, these GitHub CLI commands will limit the hosts for which gh acts as a credential helper to source authentication tokens. Additionally, GITHUB_TOKEN will only be used for GitHub.com and ghe.com.
Impact
Successful exploitation could lead to a third-party using leaked authentication tokens to access privileged resources.
Remediation and mitigation
Upgrade gh to 2.63.0
Revoke authentication tokens used with the GitHub CLI:
Personal access tokens
GitHub CLI OAuth app
Review your personal security...
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
There is a vulnerability in Traefik that allows the client to provide the X-Forwarded-Prefix header from an untrusted source.
Patches
https://github.com/traefik/traefik/releases/tag/v2.11.14
https://github.com/traefik/traefik/releases/tag/v3.2.1
Workarounds
No workaround.
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description
### Summary
The previously reported open redirect ([GHSA-6qq8-5wq3-86rp](https://github.com/traefik/traefik/security/advisories/GHSA-6qq8-5wq3-86rp)) is not fixed correctly. The safePrefix function can be tricked to return an absolute URL.
Details
The Traefik API dashboard component tries to validate that the value of the header X-Forwarded-Prefix is a site relative path:
http.Redirect(resp, req, safePrefix(req)+"/dashboard/", http.StatusFound)
func safePrefix(req *http.Request) string {
prefix := req.Header.Get("X-Forwarded-Prefix")
if prefix == "" {
return ""
}
parse, err := url.Parse(prefix)
if err != nil {
return ""
}
return parse.Path
}
PoC
An attacker can bypass this by sending the following payload:
curl -v 'http://traefik.localhost' -H 'X-Forwarded-Prefix: %0d//a.com'
[...]
> HTTP/1.1 302 Found
> Location: //a.com/dashboard/
or similar:
curl -v 'http://traefik.localhost' -H 'X-Forwarded-Prefix: %2f%2fa.com'
[...]
> HTTP/1.1 302 Found
> Location: //a.com/dashboard/
Impact
Similar to the previously report...
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
There is a vulnerability in Traefik that allows the client to provide the X-Forwarded-Prefix header from an untrusted source.
Patches
https://github.com/traefik/traefik/releases/tag/v2.11.14
https://github.com/traefik/traefik/releases/tag/v3.2.1
Workarounds
No workaround.
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description
### Summary
The previously reported open redirect ([GHSA-6qq8-5wq3-86rp](https://github.com/traefik/traefik/security/advisories/GHSA-6qq8-5wq3-86rp)) is not fixed correctly. The safePrefix function can be tricked to return an absolute URL.
Details
The Traefik API dashboard component tries to validate that the value of the header X-Forwarded-Prefix is a site relative path:
http.Redirect(resp, req, safePrefix(req)+"/dashboard/", http.StatusFound)
func safePrefix(req *http.Request) string {
prefix := req.Header.Get("X-Forwarded-Prefix")
if prefix == "" {
return ""
}
parse, err := url.Parse(prefix)
if err != nil {
return ""
}
return parse.Path
}
PoC
An attacker can bypass this by sending the following payload:
curl -v 'http://traefik.localhost' -H 'X-Forwarded-Prefix: %0d//a.com'
[...]
> HTTP/1.1 302 Found
> Location: //a.com/dashboard/
or similar:
curl -v 'http://traefik.localhost' -H 'X-Forwarded-Prefix: %2f%2fa.com'
[...]
> HTTP/1.1 302 Found
> Location: //a.com/dashboard/
Impact
Similar to the previously report...
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
The OpenID Connect implementation, in the affected SFTPGo versions, allows authenticated users to brute force session cookies and thereby gain access to other users' data, since the cookies are generated predictably using the xid library and are therefore unique but not cryptographically secure.
Patches
This issue was fixed in version v2.6.4, where cookies are opaque and cryptographically secure strings.
References
https://github.com/drakkan/sftpgo/commit/f30a9a2095bf90c0661b04fe038e3b7efc788bc6
References
https://github.com/drakkan/sftpgo/security/advisories/GHSA-6943-qr24-82vx
https://nvd.nist.gov/vuln/detail/CVE-2024-52801
https://github.com/drakkan/sftpgo/commit/f30a9a2095bf90c0661b04fe038e3b7efc788bc6
https://github.com/rs/xid
https://github.com/advisories/GHSA-6943-qr24-82vx
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet.
By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection).
As far as I understand, the kernel tracks the MTU per 4-tuple, so the attacker needs to at least know the client's IP and port tuple to mount an attack (assuming that it knows the server's IP and port).
Patches
The fix is easy: Use IP_PMTUDISC_PROBE instead of IP_PMTUDISC_DO. This socket option only sets the DF bit, but disables the kernel's MTU tracking.
Has the problem been patched? What versions should users upgrade to?
Fixed in https://github.com/quic-go/quic-go/pull/4729
Released in https://github.com/quic-go/quic-go/releases/tag/v0.48.2
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Use iptables to drop ICMP Unreachable packets.
References
Are there any links users can visit to find out more?
This bug was discovered while doing research for my new IETF draft on IP f...
December 3rd, 2024 (5 months ago)
|
|
|
Description: moby v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to trigger multiple concurrent write operations resulting in data corruption or application crashes.
References
https://nvd.nist.gov/vuln/detail/CVE-2024-36623
https://github.com/moby/moby/commit/5689dabfb357b673abdb4391eef426f297d7d1bb
https://gist.github.com/1047524396/c192c0159a19bf58a4373b696467dc29
https://github.com/moby/moby/blob/v25.0.3/pkg/streamformatter/streamformatter.go#L115
https://github.com/advisories/GHSA-gh5c-3h97-2f3q
December 3rd, 2024 (5 months ago)
|
|
|
Description: Summary:
A open redirect vulnerability exists in the loading endpoint, allowing attackers to redirect authenticated users to arbitrary external URLs via the "next" parameter.
Details:
The loading endpoint accepts and uses an unvalidated "next" parameter for redirects:
PoC:
Visit: /loading?next=https://google.com while authenticated. The page will redirect to google.com.
Impact:
This vulnerability could be used in phishing attacks by redirecting users from a legitimate application URL to malicious sites.
References
https://github.com/bunkerity/bunkerweb/security/advisories/GHSA-q9rr-h3hx-m87g
https://nvd.nist.gov/vuln/detail/CVE-2024-53264
https://github.com/advisories/GHSA-q9rr-h3hx-m87g
December 3rd, 2024 (5 months ago)
|
|
|
Description: Summary
When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}
When using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}
Details
No authentication is performed by the Server itself on client tokens[^1]. Authentication & authorization is instead delegated to the k8s API server.
However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods.
In #12736 / v3.5.7 and #13021 / v3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token.
PoC
Configuration
Controller ConfigMap:
config: |
persistence:
archive: true
postgresql:
database: argoworkflows
host: db-host
passwordSecret:
key: postgresPassword
name: argo-wf-postgres-credentials
port: 5432
tableName: argo_workflows
userNameSecret:
key: username
name: argo-wf-postgres-credentials
Server: --auth-mode...
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
Executing policy checks using custom schematron files via the CLI invokes an XSL transformation that may theoretically lead to a remote code execution (RCE) vulnerability.
Patches
We are currently working on a patch that will be released when ready.
Workarounds
This doesn't affect the standard validation and policy checks functionality, veraPDF's common use cases. Most veraPDF users don't insert any custom XSLT code into policy profiles, which are based on Schematron syntax rather than direct XSL transforms. For users who do, only load custom policy files from sources you trust.
References
Original issue: #1488
References
https://github.com/veraPDF/veraPDF-library/security/advisories/GHSA-4cx5-89vm-833x
https://nvd.nist.gov/vuln/detail/CVE-2024-52800
https://github.com/veraPDF/veraPDF-library/issues/1488
https://github.com/advisories/GHSA-4cx5-89vm-833x
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
Executing policy checks using custom schematron files via the CLI invokes an XSL transformation that may theoretically lead to a remote code execution (RCE) vulnerability.
Patches
We are currently working on a patch that will be released when ready.
Workarounds
This doesn't affect the standard validation and policy checks functionality, veraPDF's common use cases. Most veraPDF users don't insert any custom XSLT code into policy profiles, which are based on Schematron syntax rather than direct XSL transforms. For users who do, only load custom policy files from sources you trust.
References
Original issue: #1488
References
https://github.com/veraPDF/veraPDF-library/security/advisories/GHSA-4cx5-89vm-833x
https://nvd.nist.gov/vuln/detail/CVE-2024-52800
https://github.com/veraPDF/veraPDF-library/issues/1488
https://github.com/advisories/GHSA-4cx5-89vm-833x
December 3rd, 2024 (5 months ago)
|