CWE-1188
AllowedInitialization of a Resource with an Insecure Default
Abstraction: Base · Status: Incomplete
The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.
432 vulnerabilities reference this CWE, most recent first.
GHSA-XR9X-R78C-5HRM
Vulnerability from github – Published: 2026-07-30 18:23 – Updated: 2026-07-30 18:23Impact
In its default configuration, a Rails application that displays image variants may allow an
unauthenticated attacker to read arbitrary files from the server, including the process environment.
That environment typically holds secret_key_base and often credentials for external systems, which
may in turn allow escalation to remote code execution or lateral movement to those systems.
Details
libvips reads and writes file formats through "loaders" and "savers" (or more generally "operations"), many of which are backed by third-party libraries. It marks some of these operations as "unfuzzed", meaning they are unsafe for untrusted content, and several handle formats unrelated to web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload a crafted file and cause a variant to be generated from it may be able to invoke one.
We are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause disclosure of the contents of arbitrary files accessible on the filesystem of the targeted application. One specific attack chain has been reported to us (see "Disclosure" below), but we do not assume it is the only one that exists.
Affected applications
An application is affected if it meets all of these requirements:
- Uses libvips for Active Storage image processing. This is config.active_storage.variant_processor = :vips,
which load_defaults 7.0 set and no later default has changed.
- Allows image uploads from untrusted users.
Generating variants is not a separate requirement.
Mitigation
- Upgrade to a fixed version of
activestorage. - The minimum version of libvips must be upgraded to
>= 8.13. - Change
secret_key_baseand change any secrets accessible in the application environment (see "Expire and change secrets" below)
Earlier versions of libvips (< 8.13) cannot disable unfuzzed operations at all, and Active Storage
will raise an exception during boot in such an unsecurable environment.
Expire and change secrets
Upgrading closes the vulnerability but does not undo an exfiltrated secret if that already occurred. An affected application should treat every secret readable by the application process as potentially exposed and change it, including:
secret_key_base- The master key, whether stored in
config/master.keyor supplied asRAILS_MASTER_KEY, along with everything inconfig/credentials.yml.encthat it decrypts - Credentials for the Active Storage service, such as S3, GCS, or Azure keys
- Database credentials
- Tokens and keys for any third-party service the application calls
Changing secret_key_base expires active sessions and requires users to log in again. Encrypted
cookies, signed cookies, signed global IDs, and Active Storage URLs are also affected.
Rotation should only be used as an intermediate step if necessary. Do not retain an exposed secret as a fallback.
Workarounds
If libvips < 8.13 is being used, there are no workarounds available other than removing the
dependency on libvips from the application. Some applications may have ruby-vips declared as a
dependency only for image analysis, and those applications may be able to simply remove ruby-vips
from the Gemfile to remove libvips from the application. Applications that do not use Active Storage
can remove ruby-vips from the Gemfile to avoid the boot-time checks.
If libvips >= 8.13 is present on the system, applications can disable the unfuzzed operations
without upgrading Rails by setting the VIPS_BLOCK_UNTRUSTED environment variable, which libvips
reads while initializing.
Applications also running ruby-vips >= 2.2.1 or later can instead call
Vips.block_untrusted(true) from an initializer.
Releases
The fixed releases are available at the normal locations.
Versions affected
- activestorage < 7.2.3.2
- activestorage >= 8.0, < 8.0.5.1
- activestorage >= 8.1, < 8.1.3.1
Disclosure
Technical details of the attack chain are intentionally omitted from this advisory. They would add nothing to an administrator's decision to upgrade, while making it substantially easier to attack applications that have not yet done so.
Details will be disclosed no later than 2026-08-28, via the Rails Security Announcements forum.
Credit
This issue was responsibly reported by 0xacb, s3np41k1r1t0 and castilho from Ethiack, and RyotaK from GMO Flatt Security Inc..
References
- libvips 8.13 release notes, blocking of unfuzzed loaders
- W.A. Arbaugh, W.L. Fithen, and J. McHugh, "Windows of Vulnerability: A Case Study Analysis", IEEE Computer 33(12), December 2000
- https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve
- https://blog.flatt.tech/entry/kindarails2shell_rails
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "activestorage"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.2.3.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "activestorage"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0.beta1"
},
{
"fixed": "8.0.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "activestorage"
},
"ranges": [
{
"events": [
{
"introduced": "8.1.0.beta1"
},
{
"fixed": "8.1.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-66066"
],
"database_specific": {
"cwe_ids": [
"CWE-1188"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T18:23:33Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\nIn its default configuration, a Rails application that displays image variants may allow an\nunauthenticated attacker to read arbitrary files from the server, including the process environment.\nThat environment typically holds `secret_key_base` and often credentials for external systems, which\nmay in turn allow escalation to remote code execution or lateral movement to those systems.\n\n### Details\nlibvips reads and writes file formats through \"loaders\" and \"savers\" (or more generally\n\"operations\"), many of which are backed by third-party libraries. It marks some of these operations\nas \"unfuzzed\", meaning they are unsafe for untrusted content, and several handle formats unrelated\nto web images. Active Storage did not disable the unfuzzed operations, so an attacker who can upload\na crafted file and cause a variant to be generated from it may be able to invoke one.\n\nWe are aware of a mechanism by which an attacker, by uploading a crafted file, is able to cause\ndisclosure of the contents of arbitrary files accessible on the filesystem of the targeted\napplication. One specific attack chain has been reported to us (see \"Disclosure\" below), but we do\nnot assume it is the only one that exists.\n\n### Affected applications\nAn application is affected if it meets all of these requirements:\n- Uses libvips for Active Storage image processing. This is `config.active_storage.variant_processor = :vips`,\n which `load_defaults 7.0` set and no later default has changed.\n- Allows image uploads from untrusted users.\n\nGenerating variants is not a separate requirement.\n\n### Mitigation\n- Upgrade to a fixed version of `activestorage`.\n- The minimum version of libvips must be upgraded to `\u003e= 8.13`.\n- Change `secret_key_base` and change any secrets accessible in the application environment (see \"Expire and change secrets\" below)\n\nEarlier versions of libvips (`\u003c 8.13`) cannot disable unfuzzed operations at all, and Active Storage\nwill raise an exception during boot in such an unsecurable environment.\n\n### Expire and change secrets\n\nUpgrading closes the vulnerability but does not undo an exfiltrated secret if that already\noccurred. An affected application should treat every secret readable by the application process as\npotentially exposed and change it, including:\n\n- `secret_key_base`\n- The master key, whether stored in `config/master.key` or supplied as `RAILS_MASTER_KEY`, along\n with everything in `config/credentials.yml.enc` that it decrypts\n- Credentials for the Active Storage service, such as S3, GCS, or Azure keys\n- Database credentials\n- Tokens and keys for any third-party service the application calls\n\nChanging `secret_key_base` expires active sessions and requires users to log in again. Encrypted\ncookies, signed cookies, signed global IDs, and Active Storage URLs are also affected.\n\nRotation should only be used as an intermediate step if necessary. Do not retain an exposed secret\nas a fallback.\n\n### Workarounds\nIf libvips `\u003c 8.13` is being used, there are no workarounds available other than removing the\ndependency on libvips from the application. Some applications may have `ruby-vips` declared as a\ndependency only for image analysis, and those applications may be able to simply remove `ruby-vips`\nfrom the Gemfile to remove libvips from the application. Applications that do not use Active Storage\ncan remove `ruby-vips` from the Gemfile to avoid the boot-time checks.\n\nIf libvips `\u003e= 8.13` is present on the system, applications can disable the unfuzzed operations\nwithout upgrading Rails by setting the `VIPS_BLOCK_UNTRUSTED` environment variable, which libvips\nreads while initializing.\n\nApplications also running ruby-vips `\u003e= 2.2.1` or later can instead call\n`Vips.block_untrusted(true)` from an initializer.\n\n### Releases\nThe fixed releases are available at the normal locations.\n\n### Versions affected\n\n- activestorage \u003c 7.2.3.2\n- activestorage \u003e= 8.0, \u003c 8.0.5.1\n- activestorage \u003e= 8.1, \u003c 8.1.3.1\n\n### Disclosure\nTechnical details of the attack chain are intentionally omitted from this advisory. They would add\nnothing to an administrator\u0027s decision to upgrade, while making it substantially easier to attack\napplications that have not yet done so.\n\nDetails will be disclosed no later than 2026-08-28, via the [Rails Security\nAnnouncements](https://discuss.rubyonrails.org/c/security-announcements/9) forum.\n\n### Credit\nThis issue was responsibly reported by [0xacb](https://x.com/0xacb), [s3np41k1r1t0](https://x.com/s3np41k1r1t0) and [castilho](https://x.com/castilho101) from [Ethiack](https://ethiack.com), and [RyotaK](https://ryotak.net) from [GMO Flatt Security Inc.](https://flatt.tech/en/).\n\n### References\n- libvips 8.13 release notes, [blocking of unfuzzed loaders](https://www.libvips.org/2022/05/28/What\u0027s-new-in-8.13.html#blocking-of-unfuzzed-loaders)\n- W.A. Arbaugh, W.L. Fithen, and J. McHugh, [\"Windows of Vulnerability: A Case Study\n Analysis\"](https://doi.org/10.1109/2.889093), IEEE Computer 33(12), December 2000\n- https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-cve\n- https://blog.flatt.tech/entry/kindarails2shell_rails",
"id": "GHSA-xr9x-r78c-5hrm",
"modified": "2026-07-30T18:23:33Z",
"published": "2026-07-30T18:23:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/commit/1c01bb587206ee6eb0e1179c2cef96a6a47acb1e"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/commit/349e7a5d5b4b715af1e416db824f3c078a7d59e5"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/commit/d79b7f4aa17dec8ce4960fef05733c8c0c7ef49a"
},
{
"type": "PACKAGE",
"url": "https://github.com/rails/rails"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/releases/tag/v7.2.3.2"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/releases/tag/v8.0.5.1"
},
{
"type": "WEB",
"url": "https://github.com/rails/rails/releases/tag/v8.1.3.1"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/activestorage/CVE-2026-66066.yml"
},
{
"type": "WEB",
"url": "https://thehackernews.com/2026/07/critical-rails-flaw-could-let.html"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-66066"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Active Storage has possible arbitrary file read and remote code execution in Active Storage variant processing"
}
GHSA-XW59-HVM2-8PJ6
Vulnerability from github – Published: 2026-04-01 21:09 – Updated: 2026-07-21 14:58The Model Context Protocol (MCP) Go SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication with StreamableHTTPHandler or SSEHandler, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.
Note that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.
Servers created via StreamableHTTPHandler or SSEHandler now have this protection enabled by default when binding to localhost. Users are advised to update to version 1.4.0 to receive this automatic protection.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/modelcontextprotocol/go-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34742"
],
"database_specific": {
"cwe_ids": [
"CWE-1188"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:09:09Z",
"nvd_published_at": "2026-04-02T19:21:33Z",
"severity": "HIGH"
},
"details": "The Model Context Protocol (MCP) Go SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication with `StreamableHTTPHandler` or `SSEHandler`, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.\n\nNote that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.\n\nServers created via `StreamableHTTPHandler` or `SSEHandler` now have this protection enabled by default when binding to `localhost`. Users are advised to update to version `1.4.0` to receive this automatic protection.",
"id": "GHSA-xw59-hvm2-8pj6",
"modified": "2026-07-21T14:58:57Z",
"published": "2026-04-01T21:09:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/security/advisories/GHSA-xw59-hvm2-8pj6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34742"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/pull/760"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/commit/67bd3f2e2b53ce11a16db8d976cdb8ff1e986b6d"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21772"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-34742"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2454608"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/go-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/releases/tag/v1.4.0"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-34742.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "DNS Rebinding Protection Disabled by Default in Model Context Protocol Go SDK for Servers Running on Localhost"
}
No mitigation information available for this CWE.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.