CrowdStrike Image Scanner blocking n8n >= 1.123.23 (HTTP 400 Validation Error)

Questions
1

Describe the problem/error/question

We are currently blocked from deploying recent n8n security patches in our CI/CD pipeline because the CrowdStrike Falcon Container Scanner (FCS CLI) is rejecting the newer n8n Docker images.
Version n8nio/n8n:1.123.19 scans and uploads its inventory payload perfectly.
Versions >= 1.123.23 (and the 2.9.4 stable branch) consistently fail during the cloud upload phase.
We have extensively debugged this on our end and ruled out payload size limits. By trapping the temporary OCI layout generated by the scanner, we suspect CrowdStrike’s strict JSON validator is choking on a newly introduced dependency or metadata string in the newer n8n images.
Using syft to diff .19 and .23, we noticed a few major additions, including the @sigstoresigstore suite, @modelcontextprotocol/sdk, and a Go module (task-runner-launcher) using a massive pseudo-version string (v0.0.0-20260215112949-852ae3a07e57).
We also suspect there may have been an Alpine Linux base image bump between these versions.
Our Question for the n8n Team: Are you aware of any specific metadata format changes, deeply nested dependencies, or OS-level base image updates introduced between 1.123.19 and 1.123.23 that might trigger a strict SemVer or JSON validator to reject the container’s Software Bill of Materials. Is there a patch for this?

What is the error message (if any)?

Uploading image inventory to falcon cloud… (Done)
Error: error while performing scan Error details: failed to upload the results: err:received 400 from uri api.eu-1.crowdstrike.com

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

This is a CrowdStrike problem not an n8n one, that Go pseudo-version string from task-runner-launcher (v0.0.0-20260215112949-852ae3a07e57) is almost certainly what’s tripping their SBOM validator since it doesn’t follow strict semver. I’d file a bug with CrowdStrike on the fcs-action GitHub repo and in the meantime you could allowlist the image or strip the Go module metadata before scanning.

2 Likes
3

thank you for the reply i will attempt the above while i wait for crowdstrike

4

You totally called it—it’s 100% CrowdStrike choking on that weird task-runner-launcher pseudo-version string. Filing a bug on their fcs-action repo is definitely the move.

I actually tried your idea to just strip out the Go module, and man, it turned into a massive rabbit hole! Here’s how we ended up having to fix it, because just stripping the metadata wasn’t enough

First, we tried surgically removing the binary, but the scanner still caught it in the older Docker layers. We tried flattening the image (docker export / import) to wipe the history. It successfully killed the Go binary, but it also wiped out all the Docker metadata (OS, architecture, etc.) that CrowdStrike strictly needs for its SBOM. So we just traded one 400 error for another!

We ended up completely ditching the official n8nio/n8n image and building a custom one from scratch: started fresh with node:18-alpine so we had a clean OS with all the metadata fully intact. Instead of pulling the Docker image, we just ran npm install -g n8n

Thanks for your help

1 Like
5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.