Vulnerability-Lookup

GHSA-527G-FF96-X6WJ

Vulnerability from github – Published: 2026-10-20 18:11 – Updated: 2026-10-20 18:11

Summary

ApostropheCMS: Host header controls server-side image fetch origin in @apostrophecms/ai-helper, enabling authenticated SSRF

Details

Summary

The @apostrophecms/ai-helper package builds the URL for a server-side image fetch by resolving a storage-relative path against req.baseUrl. When the site does not set a global base URL (the default), req.baseUrl is derived from the incoming HTTP Host header. An authenticated editor can generate a base64 AI image (which is persisted without a stored url) and then send an unauthorized PATCH accept request with an attacker-chosen Host header. The server then issues an outbound GET to the attacker-selected origin, producing a Server-Side Request Forgery primitive that reaches hosts and ports the client cannot otherwise contact. The affected code lives in packages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js.

Root Cause

The image accept route trusts req.baseUrl as a safe origin for constructing an internal fetch target, but req.baseUrl is attacker-influenced whenever the site has no configured base URL. The URL builder concatenates a default local storage path (which is relative, for example /uploads) and resolves it against req.baseUrl; because the left operand is relative, the resulting origin is taken entirely from req.baseUrl. Two protections that exist elsewhere are missing on this path: the generate route enforces an edit capability, but the accept route performs no authorization or ownership check, and no allowlist or validation constrains the resolved origin before the fetch.

packages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js
  aiHelperImageUrl (line 91-92): image.url || new URL(self.uploadfs.getUrl() + `/ai-helper-images/${image._id}.png`, req.baseUrl)
  aiHelperFetchImage (line 64-65): fetch(self.aiHelperImageUrl(req, image))
  apiRoutes.patch['ai-helper/:_id'] (line 314-333): findOne({ _id }) only; no permission or ownership check
packages/apostrophe/modules/@apostrophecms/i18n/index.js
  setPrefixUrls (line 799-820): req.baseUrl falls back to `${req.protocol}://${host}`, host from the Host header when apos.baseUrl is unset

Impact

An attacker who holds a low-privileged editor account (the capability required to generate an AI image, which inserts a base64 record without a stored url and returns its identifier) can coerce the server into issuing outbound GET requests to an origin of their choosing by supplying a crafted Host header on the accept request. This yields SSRF: probing internal hosts and ports that are not reachable from the attacker's network position, and limited semi-blind exfiltration where an image-parseable response at the fixed path becomes a viewable attachment. The request path is fixed to /uploads/ai-helper-images/<id>.png, so only the origin (host, port, and http scheme) is attacker-controlled; arbitrary-path retrieval such as cloud metadata traversal is not reachable through this primitive. No integrity or availability primitive was demonstrated. Exploitation requires the default deployment where no global base URL is configured and local file storage is in use, together with a configured provider that returns base64 image data.

Proof of Concept

Preconditions:
  - ApostropheCMS site with @apostrophecms/ai-helper installed and a configured
    base64-returning image provider.
  - No global base URL configured (apos.baseUrl unset), default local uploadfs.
  - Attacker holds an account with edit capability on at least one content type.

Authenticate as the editor and generate a base64 AI image: POST /api/v1/@apostrophecms/image/ai-helper with body {"prompt":"x"}. The response contains the new record identifier <_id>. The persisted record has no url field.
Send the accept request with a malicious Host header:

PATCH /api/v1/@apostrophecms/image/ai-helper/<_id> HTTP/1.1
Host: 169.254.169.254
Content-Type: application/json

{"accepted": true}

The server derives req.baseUrl as http://169.254.169.254, builds the fetch target http://169.254.169.254/uploads/ai-helper-images/<_id>.png, and issues the outbound request.

Derivation confirmed against source logic:
  base64 record (no url) + Host: 169.254.169.254
    -> new URL("/uploads/ai-helper-images/<_id>.png", "http://169.254.169.254")
    -> server fetches: http://169.254.169.254/uploads/ai-helper-images/<_id>.png
  control (apos.baseUrl set to https://cms.example.com):
    -> fetch target uses https://cms.example.com (Host ignored)
  control (record stores its own url):
    -> aiHelperImageUrl short-circuits to the stored url (no SSRF)

Attack Chain

Exposure: The @apostrophecms/ai-helper-image module registers POST and PATCH routes under /api/v1/@apostrophecms/image/ai-helper, reachable by any authenticated session on a site that installed the package.
Control: The attacker controls the HTTP Host header on the PATCH request; the global locale middleware copies it into req.baseUrl because apos.baseUrl is unset (packages/apostrophe/modules/@apostrophecms/i18n/index.js:805,816-819).
Path: The attacker first generates a base64 image via POST, which inserts a record without a url (ai-helper-image/index.js:282-284); the returned identifier is then used in the PATCH accept request, which calls aiHelperFetchImage (:332).
Guard: The PATCH handler checks only req.body.accepted and record existence via findOne({ _id }) (:318,:322); it performs no capability check and no owner scoping, unlike the POST route which calls checkPermissions (:176). No validation constrains the resolved origin before the fetch.
Primitive: aiHelperImageUrl resolves the relative storage path against the Host-derived req.baseUrl and aiHelperFetchImage calls fetch on the result (:91-92,:64-65).
Result: The server performs an outbound GET to the attacker-chosen origin at a fixed path, granting internal host and port reachability and limited semi-blind response retrieval that the attacker's network position does not otherwise permit.

Bypass Evidence

The generate route's checkPermissions guard (ai-helper-image/index.js:176) is not present on the accept route, so no authorization protects the fetch. The following refutations were tested and defeated:

Default local storage returns a relative URL: uploadfs.getUrl() yields /uploads because the local backend builds uploadsUrl = (apos.baseUrl || '') + prefix + '/uploads', so new URL(relative, req.baseUrl) takes its origin from req.baseUrl. Configuring a base URL or an absolute storage URL (S3/CDN) defeats the attack, which is why those are negative controls, not the default.
The base64 record has no persisted url: insertOne(image) stores the record before image.url is assigned on the in-memory response object (:282-284 versus :294), so the PATCH handler re-reads a record with no url and the short-circuit in aiHelperImageUrl does not apply.
Ownership and enumeration: GET and DELETE on these records are userId-scoped and cuid2 identifiers are unguessable, so the practical actor is the generating editor; this bounds the required privilege to a low-privileged authenticated user rather than an anonymous or cross-tenant attacker.
Not a duplicate: the fix for the core pretty-URL SSRF advisory lives entirely in the separate @apostrophecms/file module and its stream proxy and never touches packages/ai-helper; the rich-text import SSRF advisory uses a different route with an explicit hostname allowlist. No advisory exists for @apostrophecms/ai-helper. This is a parallel unguarded sink, not an incomplete fix of either.

Affected Versions

Ecosystem: npm
Package: @apostrophecms/ai-helper
Confirmed affected range: >= 1.0.0-beta.10, <= 1.0.0-beta.12
Latest release checked: 1.0.0-beta.12 (npm registry, dist-tag latest)
Fix status: not fixed

The vulnerable pattern was introduced in 1.0.0-beta.10: earlier releases through 1.0.0-beta.9 fetched the stored provider URL directly (fetch(url)) with no req.baseUrl resolution and no uploadfs-relative construction, so they are not affected by this pattern. Inspection of the published tarballs for 1.0.0-beta.10, 1.0.0-beta.11, and 1.0.0-beta.12 confirms the full chain (Host-derived base resolution, unguarded accept route, base64 insert without a stored url) is present and unchanged through the latest published release. This package publishes only on the prerelease (beta) channel, and the latest published version remains vulnerable.

Suggested Fix

Do not treat req.baseUrl as a trusted origin for a server-side fetch. Enforce the same authorization on the accept route that the generate route applies, and add an ownership or scope check so a record can only be accepted by a user permitted to act on it. Independently, constrain the fetch target: resolve the storage-relative path against a server-configured, trusted base (for example the configured storage base URL) rather than the request-derived req.baseUrl, and reject or allowlist any resulting origin before calling fetch. Ensure the remediation covers both the base64 (no stored url) representation and the stored-url representation, and any other caller that reaches aiHelperImageUrl or aiHelperFetchImage. As an interim mitigation without a code change, configure a global base URL so the resolved origin is fixed, and place egress controls on the server so outbound requests cannot reach sensitive internal hosts or metadata endpoints.

Reported by zx (GitHub: @manus-pi).

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@apostrophecms/ai-helper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-beta.10"
            },
            {
              "fixed": "1.0.0-beta.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-113671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-20T18:11:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `@apostrophecms/ai-helper` package builds the URL for a server-side image fetch by resolving a storage-relative path against `req.baseUrl`. When the site does not set a global base URL (the default), `req.baseUrl` is derived from the incoming HTTP `Host` header. An authenticated editor can generate a base64 AI image (which is persisted without a stored `url`) and then send an unauthorized `PATCH` accept request with an attacker-chosen `Host` header. The server then issues an outbound `GET` to the attacker-selected origin, producing a Server-Side Request Forgery primitive that reaches hosts and ports the client cannot otherwise contact. The affected code lives in `packages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js`.\n\n## Root Cause\n\nThe image accept route trusts `req.baseUrl` as a safe origin for constructing an internal fetch target, but `req.baseUrl` is attacker-influenced whenever the site has no configured base URL. The URL builder concatenates a default local storage path (which is relative, for example `/uploads`) and resolves it against `req.baseUrl`; because the left operand is relative, the resulting origin is taken entirely from `req.baseUrl`. Two protections that exist elsewhere are missing on this path: the generate route enforces an edit capability, but the accept route performs no authorization or ownership check, and no allowlist or validation constrains the resolved origin before the fetch.\n\n```text\npackages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js\n  aiHelperImageUrl (line 91-92): image.url || new URL(self.uploadfs.getUrl() + `/ai-helper-images/${image._id}.png`, req.baseUrl)\n  aiHelperFetchImage (line 64-65): fetch(self.aiHelperImageUrl(req, image))\n  apiRoutes.patch[\u0027ai-helper/:_id\u0027] (line 314-333): findOne({ _id }) only; no permission or ownership check\npackages/apostrophe/modules/@apostrophecms/i18n/index.js\n  setPrefixUrls (line 799-820): req.baseUrl falls back to `${req.protocol}://${host}`, host from the Host header when apos.baseUrl is unset\n```\n\n## Impact\n\nAn attacker who holds a low-privileged editor account (the capability required to generate an AI image, which inserts a base64 record without a stored `url` and returns its identifier) can coerce the server into issuing outbound `GET` requests to an origin of their choosing by supplying a crafted `Host` header on the accept request. This yields SSRF: probing internal hosts and ports that are not reachable from the attacker\u0027s network position, and limited semi-blind exfiltration where an image-parseable response at the fixed path becomes a viewable attachment. The request path is fixed to `/uploads/ai-helper-images/\u003cid\u003e.png`, so only the origin (host, port, and `http` scheme) is attacker-controlled; arbitrary-path retrieval such as cloud metadata traversal is not reachable through this primitive. No integrity or availability primitive was demonstrated. Exploitation requires the default deployment where no global base URL is configured and local file storage is in use, together with a configured provider that returns base64 image data.\n\n## Proof of Concept\n\n```text\nPreconditions:\n  - ApostropheCMS site with @apostrophecms/ai-helper installed and a configured\n    base64-returning image provider.\n  - No global base URL configured (apos.baseUrl unset), default local uploadfs.\n  - Attacker holds an account with edit capability on at least one content type.\n```\n\n1. Authenticate as the editor and generate a base64 AI image:\n   `POST /api/v1/@apostrophecms/image/ai-helper` with body `{\"prompt\":\"x\"}`. The response contains the new record identifier `\u003c_id\u003e`. The persisted record has no `url` field.\n2. Send the accept request with a malicious `Host` header:\n\n```text\nPATCH /api/v1/@apostrophecms/image/ai-helper/\u003c_id\u003e HTTP/1.1\nHost: 169.254.169.254\nContent-Type: application/json\n\n{\"accepted\": true}\n```\n\n3. The server derives `req.baseUrl` as `http://169.254.169.254`, builds the fetch target `http://169.254.169.254/uploads/ai-helper-images/\u003c_id\u003e.png`, and issues the outbound request.\n\n```text\nDerivation confirmed against source logic:\n  base64 record (no url) + Host: 169.254.169.254\n    -\u003e new URL(\"/uploads/ai-helper-images/\u003c_id\u003e.png\", \"http://169.254.169.254\")\n    -\u003e server fetches: http://169.254.169.254/uploads/ai-helper-images/\u003c_id\u003e.png\n  control (apos.baseUrl set to https://cms.example.com):\n    -\u003e fetch target uses https://cms.example.com (Host ignored)\n  control (record stores its own url):\n    -\u003e aiHelperImageUrl short-circuits to the stored url (no SSRF)\n```\n\n## Attack Chain\n\n1. **Exposure:** The `@apostrophecms/ai-helper-image` module registers `POST` and `PATCH` routes under `/api/v1/@apostrophecms/image/ai-helper`, reachable by any authenticated session on a site that installed the package.\n2. **Control:** The attacker controls the HTTP `Host` header on the `PATCH` request; the global `locale` middleware copies it into `req.baseUrl` because `apos.baseUrl` is unset (`packages/apostrophe/modules/@apostrophecms/i18n/index.js:805,816-819`).\n3. **Path:** The attacker first generates a base64 image via `POST`, which inserts a record without a `url` (`ai-helper-image/index.js:282-284`); the returned identifier is then used in the `PATCH` accept request, which calls `aiHelperFetchImage` (`:332`).\n4. **Guard:** The `PATCH` handler checks only `req.body.accepted` and record existence via `findOne({ _id })` (`:318,:322`); it performs no capability check and no owner scoping, unlike the `POST` route which calls `checkPermissions` (`:176`). No validation constrains the resolved origin before the fetch.\n5. **Primitive:** `aiHelperImageUrl` resolves the relative storage path against the Host-derived `req.baseUrl` and `aiHelperFetchImage` calls `fetch` on the result (`:91-92,:64-65`).\n6. **Result:** The server performs an outbound `GET` to the attacker-chosen origin at a fixed path, granting internal host and port reachability and limited semi-blind response retrieval that the attacker\u0027s network position does not otherwise permit.\n\n## Bypass Evidence\n\nThe generate route\u0027s `checkPermissions` guard (`ai-helper-image/index.js:176`) is not present on the accept route, so no authorization protects the fetch. The following refutations were tested and defeated:\n\n- Default local storage returns a relative URL: `uploadfs.getUrl()` yields `/uploads` because the local backend builds `uploadsUrl = (apos.baseUrl || \u0027\u0027) + prefix + \u0027/uploads\u0027`, so `new URL(relative, req.baseUrl)` takes its origin from `req.baseUrl`. Configuring a base URL or an absolute storage URL (S3/CDN) defeats the attack, which is why those are negative controls, not the default.\n- The base64 record has no persisted `url`: `insertOne(image)` stores the record before `image.url` is assigned on the in-memory response object (`:282-284` versus `:294`), so the `PATCH` handler re-reads a record with no `url` and the short-circuit in `aiHelperImageUrl` does not apply.\n- Ownership and enumeration: `GET` and `DELETE` on these records are `userId`-scoped and cuid2 identifiers are unguessable, so the practical actor is the generating editor; this bounds the required privilege to a low-privileged authenticated user rather than an anonymous or cross-tenant attacker.\n- Not a duplicate: the fix for the core pretty-URL SSRF advisory lives entirely in the separate `@apostrophecms/file` module and its stream proxy and never touches `packages/ai-helper`; the rich-text import SSRF advisory uses a different route with an explicit hostname allowlist. No advisory exists for `@apostrophecms/ai-helper`. This is a parallel unguarded sink, not an incomplete fix of either.\n\n## Affected Versions\n\n- `Ecosystem: npm`\n- `Package: @apostrophecms/ai-helper`\n- `Confirmed affected range: \u003e= 1.0.0-beta.10, \u003c= 1.0.0-beta.12`\n- `Latest release checked: 1.0.0-beta.12 (npm registry, dist-tag latest)`\n- `Fix status: not fixed`\n\nThe vulnerable pattern was introduced in `1.0.0-beta.10`: earlier releases through `1.0.0-beta.9` fetched the stored provider URL directly (`fetch(url)`) with no `req.baseUrl` resolution and no uploadfs-relative construction, so they are not affected by this pattern. Inspection of the published tarballs for `1.0.0-beta.10`, `1.0.0-beta.11`, and `1.0.0-beta.12` confirms the full chain (Host-derived base resolution, unguarded accept route, base64 insert without a stored url) is present and unchanged through the latest published release. This package publishes only on the prerelease (beta) channel, and the latest published version remains vulnerable.\n\n## Suggested Fix\n\nDo not treat `req.baseUrl` as a trusted origin for a server-side fetch. Enforce the same authorization on the accept route that the generate route applies, and add an ownership or scope check so a record can only be accepted by a user permitted to act on it. Independently, constrain the fetch target: resolve the storage-relative path against a server-configured, trusted base (for example the configured storage base URL) rather than the request-derived `req.baseUrl`, and reject or allowlist any resulting origin before calling `fetch`. Ensure the remediation covers both the base64 (no stored url) representation and the stored-url representation, and any other caller that reaches `aiHelperImageUrl` or `aiHelperFetchImage`. As an interim mitigation without a code change, configure a global base URL so the resolved origin is fixed, and place egress controls on the server so outbound requests cannot reach sensitive internal hosts or metadata endpoints.\n\nReported by zx (GitHub: @manus-pi).",
  "id": "GHSA-527g-ff96-x6wj",
  "modified": "2026-10-20T18:11:01Z",
  "published": "2026-10-20T18:11:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-527g-ff96-x6wj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/f84fd41cbf6c22eb8d0008fc9c25df1f7130b350"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apostrophecms/apostrophe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/releases/tag/@apostrophecms/ai-helper@1.0.0-beta.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ApostropheCMS: Host header controls server-side image fetch origin in @apostrophecms/ai-helper, enabling authenticated SSRF"
}

CVE-2026-113671 (GCVE-0-2026-113671)

Vulnerability from cvelistv5 – Published: 2026-10-20 17:43 – Updated: 2026-10-20 18:21

Title

ApostropheCMS: Host header controls server-side image fetch origin in @apostrophecms/ai-helper, enabling authenticated SSRF

Summary

ApostropheCMS is an open-source Node.js content management system. From 1.0.0-beta.10 until 1.0.0-beta.13 of the AI helper, an editor with image-generation capability can create a base64-generated image record without a stored provider URL and invoke image acceptance on a deployment using local relative storage with no trusted global base URL. The server resolves the fixed uploads path against a request-controlled Host-derived origin, enabling bounded server-side requests to an attacker-selected host, port, and HTTP origin, but not arbitrary-path retrieval or the stored-provider and absolute-storage configurations. This issue is fixed in AI helper 1.0.0-beta.13.

Severity

4.3 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-20 18:20 UTC

CWE

CWE-918 - Server-Side Request Forgery (SSRF)

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7639 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/apostrophecms/apostrophe/secur…	x_refsource_CONFIRM
https://github.com/apostrophecms/apostrophe/commi…	x_refsource_MISC
https://github.com/apostrophecms/apostrophe/commi…	x_refsource_MISC
https://github.com/apostrophecms/apostrophe/relea…	x_refsource_MISC

Impacted products

2 products

Vendor	Product	Version
apostrophecms	apostrophe	Affected: >= 4.25.0, < 4.33.0
@apostrophecms	ai-helper	Affected: >= 1.0.0-beta.10, < 1.0.0-beta.13

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-113671",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-20T18:20:48.654708Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-20T18:21:05.814Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-527g-ff96-x6wj"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "apostrophe",
          "vendor": "apostrophecms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.25.0, \u003c 4.33.0"
            }
          ]
        },
        {
          "product": "ai-helper",
          "vendor": "@apostrophecms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.0.0-beta.10, \u003c 1.0.0-beta.13"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ApostropheCMS is an open-source Node.js content management system. From 1.0.0-beta.10 until 1.0.0-beta.13 of the AI helper, an editor with image-generation capability can create a base64-generated image record without a stored provider URL and invoke image acceptance on a deployment using local relative storage with no trusted global base URL. The server resolves the fixed uploads path against a request-controlled Host-derived origin, enabling bounded server-side requests to an attacker-selected host, port, and HTTP origin, but not arbitrary-path retrieval or the stored-provider and absolute-storage configurations. This issue is fixed in AI helper 1.0.0-beta.13."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-918",
              "description": "CWE-918: Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T17:43:53.227Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-527g-ff96-x6wj",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-527g-ff96-x6wj"
        },
        {
          "name": "https://github.com/apostrophecms/apostrophe/commit/9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/apostrophecms/apostrophe/commit/9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce"
        },
        {
          "name": "https://github.com/apostrophecms/apostrophe/commit/f84fd41cbf6c22eb8d0008fc9c25df1f7130b350",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/apostrophecms/apostrophe/commit/f84fd41cbf6c22eb8d0008fc9c25df1f7130b350"
        },
        {
          "name": "https://github.com/apostrophecms/apostrophe/releases/tag/@apostrophecms/ai-helper@1.0.0-beta.13",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/apostrophecms/apostrophe/releases/tag/@apostrophecms/ai-helper@1.0.0-beta.13"
        }
      ],
      "source": {
        "advisory": "GHSA-527g-ff96-x6wj",
        "discovery": "UNKNOWN"
      },
      "title": "ApostropheCMS: Host header controls server-side image fetch origin in @apostrophecms/ai-helper, enabling authenticated SSRF"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-113671",
    "datePublished": "2026-10-20T17:43:53.227Z",
    "dateReserved": "2026-10-20T14:27:46.642Z",
    "dateUpdated": "2026-10-20T18:21:05.814Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-527G-FF96-X6WJ

Summary

Root Cause

Impact

Proof of Concept

Attack Chain

Bypass Evidence

Affected Versions

Suggested Fix

CVE-2026-113671 (GCVE-0-2026-113671)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour