CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!
Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
|
Description: Summary
There is a possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer 1.6.0 when used with Rails >= 7.1.0 and Nokogiri < 1.15.7, or 1.16.x < 1.16.8.
Versions affected: 1.6.0
Not affected: < 1.6.0
Fixed versions: 1.6.1
Please note that the fix in v1.6.1 is to update the dependency on Nokogiri to 1.15.7 or >= 1.16.8.
Impact
A possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer may allow an attacker to inject content if HTML5 sanitization is enabled and the application developer has overridden the sanitizer's allowed tags in either of the following ways:
allow both "math" and "style" elements
or allow both "svg" and "style" elements
Code is only impacted if Rails is configured to use HTML5 sanitization, please see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information on these configuration options.
Code is only impacted if allowed tags are being overridden. Applications may be doing this in a few different ways:
using application configuration to configure Action View sanitizers' allowed tags:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["math", "style"]
# or
config.action_view.sanitized_allowed_tags = ["svg", "style"]
see https://guides.rubyonrails.org/configuring.html#configuring-action-view
using a :tags option to the Action View helper sanitize:
<%= sanitize @comment.body, tags: ["math", "style"] %&...
December 3rd, 2024 (6 months ago)
|
|
|
Description: Summary
There is a possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer 1.6.0 when used with Rails >= 7.1.0.
Versions affected: 1.6.0
Not affected: < 1.6.0
Fixed versions: 1.6.1
Impact
A possible XSS vulnerability with certain configurations of Rails::HTML::Sanitizer may allow an attacker to inject content if HTML5 sanitization is enabled and the application developer has overridden the sanitizer's allowed tags in the following way:
the "noscript" element is explicitly allowed
Code is only impacted if Rails is configured to use HTML5 sanitization, please see documentation for config.action_view.sanitizer_vendor and config.action_text.sanitizer_vendor for more information on these configuration options.
The default configuration is to disallow all of these elements. Code is only impacted if allowed tags are being overridden. Applications may be doing this in a few different ways:
using application configuration to configure Action View sanitizers' allowed tags:
# In config/application.rb
config.action_view.sanitized_allowed_tags = ["noscript"]
see https://guides.rubyonrails.org/configuring.html#configuring-action-view
using a :tags option to the Action View helper sanitize:
<%= sanitize @comment.body, tags: ["noscript"] %>
see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize
setting Rails::HTML5::SafeListSanitizer class attribute allowed_tags:
# class-level option
Rails::HTML...
December 3rd, 2024 (6 months ago)
|
|
|
Description: Summary
A security vulnerability has been identified in go-gh that could leak authentication tokens intended for GitHub hosts to non-GitHub hosts when within a codespace.
Details
go-gh sources authentication tokens from different environment variables depending on the host involved:
GITHUB_TOKEN, GH_TOKEN for GitHub.com and ghe.com
GITHUB_ENTERPRISE_TOKEN, GH_ENTERPRISE_TOKEN for GitHub Enterprise Server
Prior to 2.11.1, auth.TokenForHost could source a token from the GITHUB_TOKEN environment variable for a host other than GitHub.com or ghe.com when within a codespace.
In 2.11.1, auth.TokenForHost will only source a token from the GITHUB_TOKEN environment variable for GitHub.com or ghe.com hosts.
Impact
Successful exploitation could send authentication token to an unintended host.
Remediation and mitigation
Upgrade go-gh to 2.11.1
Advise extension users to regenerate authentication tokens:
Personal access tokens
GitHub CLI OAuth app
Advise extension users to review their personal security log and any relevant audit logs for actions associated with their account or enterprise
References
https://github.com/cli/go-gh/security/advisories/GHSA-55v3-xh23-96gh
https://nvd.nist.gov/vuln/detail/CVE-2024-53859
https://docs.github.com/en/apps/using-github-apps/reviewing-and-revoking-authorization-of-github-apps#reviewing-your-authorized-github-apps
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log
https://docs.github.co...
December 3rd, 2024 (6 months ago)
|
|
|
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 (6 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 (6 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 (6 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 (6 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 (6 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 (6 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 (6 months ago)
|