CheckMK, RobotMK and RCC environment for CVE-2026-111497

Checkmk Dev&Exchange
1

CheckMK 2.5.0p15 (current) UltimateMT

REF NVD-CVE-2026-111497

Looking through the werk list and couldn’t find any references to this CVE but my robot endpoints are all being flagged for it by security software.

I know RCC was deprecated by Robocorp but there was some mention of CheckMK forking it. It is listed as the preferred method still. However, I also see the alternative of using “CSM,” based on Micromamba.

Before I begin migration, are there any planned updates to address this particular CVE? The 2.5.0p19 release about to drop address several other CVEs so thought I’d ask.

Sincerely,

Scotsie

2

@simonm can you weigh in on this :)?

3

Hi Scott,

thanks for raising this.

Do you have any more detailed information what the security scanners have detected?

From what I see, RCC is not affected; the RCC binary doesn’t include or link any Brotli implementation.
The micromamba binary that RCC uses also contains no Brotli decoder.

There are 2 reasons why your scanner flags the endpoints:

  1. The node.js version installed into the environment; all Node.js versions below 22.23.4 / 24.22.1 / 26.12.1 contain an affected node binary
  2. The Webkit browser: Running rfbrowser init without arguments downloads every Playwright browser, including WebKit. WebKit ships libbrotlidec.so.1.0.7, which is also in the affected range.

Recommendations:

NodeJS:

Option 1: Update Node.js in your conda.yaml to a fixed version (≥ 22.23)
Option 2: Alternatively, remove nodejs from conda.yaml and use the BrowserLibrary “batteries included” package, which comes with the runtime bundled instead - no need to specify Nodejs in the dependencies then.

Webkit: If you do not have the need to test with Webkit explicitly, change the postinstall script to rfbrowser init chromium or rfbrowser init firefox which skips the Webkit installation.

conda.yaml:

channels:
  - conda-forge
dependencies:
  - python=3.12
  - pip=23.2.1
  - pip:
      - robotframework>=7.5
      - robotframework-browser[bb]>=21.0

# Install Browser binaries after environment creation.
rccPostInstall:
  - rfbrowser init chromium

Summary/Classification

The CVSS score of 9.8 assumes a server that accepts and decompresses Brotli data from the network.
But this doesn’t apply to Robotmk.
The Node.js process used by the Browser Library is not a server.
It only talks to Python over a local gRPC channel, and that channel doesn’t use Brotli.

The exception is WebKit, which decompresses whatever content a visited page delivers.
It matters only if tests actually run in WebKit; if it is just installed and unused, it is only a file on disk.
If the robots only test trusted internal applications, I rate the practical risk as low to medium.
It is higher of course if the robots test external websites, use WebKit, or run under a privileged account, since the flaw can also leak memory such as test credentials.

Feel free to ask if there are still open questions.

Best regards, Simon

4

@gstolz thank you for the referral.

@simonm,
The report I got was rather vague (and long) so I’m trying to get more details. However, it’s a bit of a game of telephone (passing from person to person down to me).

All of my conda.yaml configs do install nodejs but do not specify a version assuming that would update as needed.

I also am specifying the chromium-headless-shell browser specifically so don’t think webkit is involved.

channels:
    - conda-forge
dependencies:
    - python=3.11
    - pip
    - robocorp-truststore
    - nodejs
    - pip:
        - robotframework
        - robotframework-browser
rccPostInstall:
    - rfbrowser init chromium-headless-shell

If the node version remains static with caching, is a quick yaml file change enough to alter the hash of the file and trigger a rebuild to pull an updated release?

Also, thank you for this information. I’m chasing down all sort of related item so this helps cross one more item off my urgent list.

Sincerely,
Scotsie

5

As a follow up, the scanner was reading into the holotree files and as mentioned, nodejs had pulled down and cached 1.2.0 for brotli related libraries.

$ find /opt/robotmk/rcc_home/current_user/holotree -path "*/conda-meta/*brotli*.json" -printf "%f\n" 2>/dev/null | sort -u
  libbrotlicommon-1.2.0-hb03c661_1.json
  libbrotlidec-1.2.0-hb03c661_1.json
  libbrotlienc-1.2.0-hb03c661_1.json

Since I had not pinned a version in my conda.yaml, I went with the method of:

  • Catch a momentum when no checks were running
    pgrep -af "/opt/checkmk/agent/default/package/robotmk/rcc" || true
  • Run the rcc configuration as the cmk-agent user with environmental context for the correct folder folder:
$ ROBOCORP_HOME=/opt/robotmk/rcc_home/current_user \
/opt/checkmk/agent/default/package/robotmk/rcc configuration cleanup --all

This purged everything and when I re-enabled the rule, rebuilt the environment with the 1.2.1 build.

Sincerely,

Scotsie

6

Hi Scott,

Thanks for the further details.

As a general rule, I recommend always pinning the versions in the conda.yaml file – at least down to the minor version.

That way, you’ll include patch releases when rebuilding, but you won’t run the risk of jumping straight to a major version.
(I don’t consider a severe problem with Node.js, but in case of a library it could lead to incompatibilities…)

Yes, exactly, but:
The Robotmk Scheduler builds the environments via RCC only on restart (= i.e. when you restart the Checkmk agent, the Scheduler also restarts).

RCC then creates an environment under two conditions:

  1. The environment does not yet exist
  2. The environment exists, but the hash of the conda.yaml file has changed (e.g. due to version changes or changes to the packages). The changes must be semantic; whitespaces, newlines and also comments do not count.

:cross_mark: What doesn’t work, however: not specifying a version and expecting that RCC will keep the package up to date during operation, so that you always remain up to date.
The latest version of a package is only fetched at the time when the environment is actually (re)built.

In your case, it would therefore have been sufficient to pin NodeJS to a specific version and restart the CheckMK agent.

Yes, in that case you won’t get a WebKit browser – and you won’t have a Brotli dependency either.
That’s fine.

Your approach to cleaning things up was exemplary! :slight_smile:
That purges all the environments.
Alternatively, you could also remove the rcc_home directory, as it contains all the environments, and restart the scheduler.

Oh, and one more thing: the Browser Library documentation has since been completely revamped and it’s turned out really well.
The “Browser-batteries” package is now the recommended method, I’ve updated my training materials accordingly.

It’s very handy that the library version now always comes with a matching Node version as a binary in the wheel.

In my conda example above, I made one mistake: rfbrowser init is the command for installing the Node dependencies (including downloading the browser(s)).

However, if you’re using browser-batteries, rfbrowser install is the correct command, which only installs the browsers (the Node dependencies are included with the wheel).

So the correct conda.yaml is:

channels:
  - conda-forge
dependencies:
  - python=3.12
  - pip=23.2.1
  - pip:
      - robotframework>=7.5
      - robotframework-browser[bb]>=21.0

rccPostInstall:
  - rfbrowser install chromium

Best regards,
Simon