iobroker.securitycheck --- Brainstorming

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 19:33:29 GMT

Thomas Braun — Thu, 09 Apr 2026 19:33:29 GMT

@OliverIO sagte:

das sind Wünsche aus der IT-Ecke.

Natürlich ist das Wunschdenken, ist mir auch klar.

In der Praxis sind viele Consumer-Geräte mit AutoUpdate ausgestattet.

Ja, mit den üblichen Dingen. Ich habe z. B. bewusst auf meinen Kisten kein AutoUpdate konfiguriert, ich sehe gerne was sich da ändert und spiele das dann bewusst ein. Dann hab ich auch eine Chance zu sehen bei welchem Update es vielleicht haken könnte. Klar, kann auch nicht jeder. Aber dann aus der Unsicherheit heraus lieber gar nichts zu machen ist halt auch falsch und führt dann zu diesen oft hoffnungslos abgesoffenen, 'never getatschten' Wracks.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 19:31:04 GMT

OliverIO — Thu, 09 Apr 2026 19:31:04 GMT

@Thomas-Braun

das sind Wünsche aus der IT-Ecke.
In der Praxis sind viele Consumer-Geräte mit AutoUpdate ausgestattet.
Aber auch das ist aufwändig, da du alle konstellationen ständig testen musst, wenn
du nach einem update keine oder nur wenige elektronische backsteine produzieren willst.

ich möchte nicht wissen welchen aufwand apple oder google betreibt um das mit den handys einigermaßen so hinzubekommen.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 19:17:54 GMT

Thomas Braun — Thu, 09 Apr 2026 19:17:54 GMT

@OliverIO

Richtig. Aber es kann auch nicht sein, das die Kisten über Jahre nicht mehr angepackt werden.
Das hat auch nix mehr mit Systemadministrator oder nicht zu tun. Wenn du ein Computersystem aufsetzt und betreibst bist du dann auch der 'Systemadministrator' für den Hobel. Oder du stellst jemanden dafür ein, der dir die Aufgabe abnimmt. Macht natürlich privat keiner. Also musste da selber regelmäßig ran. Die Betonung auf regelmäßig, nicht zwingendermaßen sofort.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 19:02:56 GMT

OliverIO — Thu, 09 Apr 2026 19:02:56 GMT

@Thomas-Braun

ein großteil der benutzer sind auch keine systemadministratoren die oft sich um das system kümmern können/wollen.
müssen ggfs auch in der familie noch ein paar andere aufgaben administrieren

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 18:57:03 GMT

Thomas Braun — Thu, 09 Apr 2026 18:57:03 GMT

@OliverIO sagte:

Auch jetzt wird ja bei dringender Änderung nicht wirklich alles innerhalb kürzester Zeit aktualisiert.

Das stimmt natürlch leider. Die 'never tatsch irgendwas'-Herangehensweise von einigen usern ist halt nicht kleinzukriegen.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 18:55:26 GMT

OliverIO — Thu, 09 Apr 2026 18:55:26 GMT

@Thomas-Braun
Da muss man halt dann auch abwägen was wichtiger ist
und wie groß der Pufferzeitraum ist (1 Tag, 1 Woche?)
Auch jetzt wird ja bei dringender Änderung nicht wirklich alles innerhalb kürzester Zeit aktualisiert.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 18:52:58 GMT

Thomas Braun — Thu, 09 Apr 2026 18:52:58 GMT

@OliverIO

Wobei das halt auch Module ausbremst, die drigend gepatcht werden müssten. Außer du pflegst dann eine Whitelist.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 18:53:06 GMT

OliverIO — Thu, 09 Apr 2026 18:53:06 GMT

die KI hat auch nicht wirklich handhabbare Lösungen (meist solche die im business Umfeld eingesetzt werden, aber für ein OpenSource Projekt nicht wirklich handhabbar wäre, da zu aufwändig)

Auf npm Ebene wäre eigentlich auch so ein dependabot cooldown sinnvoll, das bei installtion nicht die pakete gezogen werden, die gerade eben erst aktualisiert wurden, sonder idealerweise mit einer Woche Verzögerung.
Dann gäbe es zumindest einen Puffer in der diese problematischen Pakete entdeckt werden können. Das erfolgte ja bisher immer recht schnell (hoffentlich, zumindest von denen wo man gehört hat)

Nachtrag:

Das gibt es tatsächlich. npm install hat einen Parameter before
https://docs.npmjs.com/cli/v8/using-npm/config#before
Der sorgt dafür, das die dependencies so aufgelöst werden wie sie zu diesem Datum aufgelöst worden wären.
Darüber könnte man dann einen Puffer einführen.
Würde aber wahrscheinlich auch bedeuten, das neue Adapter versionen ebenfalls solange brauchen bis sie bei allen überhaupt ankommen.

https://docs.npmjs.com/cli/v8/using-npm/config#before

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 18:35:23 GMT

OliverIO — Thu, 09 Apr 2026 18:35:23 GMT

@Thomas-Braun

Wenn dann wäre es die Quelle für eine Funktion die dann Infos ausgibt bzw irgend ein Update dann blockiert

Hab ja geschrieben ein Nutzer kann das nicht wirklich auswerten. Auch ich tu mich da schwer.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 18:33:58 GMT

Thomas Braun — Thu, 09 Apr 2026 18:33:58 GMT

@OliverIO

Die Ausgabe von npm audit verleitet allerdings sehr schnell dazu dann da per npm audit fix --force das ganze Ding in die Binsen zu hauen.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 18:33:57 GMT

OliverIO — Thu, 09 Apr 2026 18:33:57 GMT

@Feuersturm

Die richtige Stelle wäre eigentlich der folgende Befehl

https://docs.npmjs.com/cli/v9/commands/npm-audit

Nach dem ersten größeren SupplyChain Attacks hatte ich da mal reingeschaut, allerdings ist das nix was ein Nutzer wirklich richtig interpretieren kann bzw. steht da auch viel drin, das momentan aktzepabel wäre.

das ist eine Ausgabe einer relativ aktuellen Testinstallation
Auf der Konsole sind dann noch ein paar extra Farben mit dabei, die das einfacher zum lesen macht.
Alternativ kann man sich das auch als JSON ausgeben lassen bzw. die Meldungen vorfiltern.

# npm audit report

ajv  <6.14.0 || >=7.0.0-alpha.0 <8.18.0
Severity: moderate
ajv has ReDoS when using `$data` option - https://github.com/advisories/GHSA-2g4f-4pwh-qvx6
ajv has ReDoS when using `$data` option - https://github.com/advisories/GHSA-2g4f-4pwh-qvx6
fix available via `npm audit fix`
node_modules/ajv
node_modules/har-validator/node_modules/ajv

axios  <1.15.0
Severity: critical
Axios has a NO_PROXY Hostname Normalization Bypass Leads to SSRF - https://github.com/advisories/GHSA-3p68-rc4w-qgx5
fix available via `npm audit fix`
node_modules/axios

brace-expansion  <=1.1.12 || 2.0.0 - 2.0.2
Severity: moderate
brace-expansion Regular Expression Denial of Service vulnerability - https://github.com/advisories/GHSA-v6h2-p8h4-qcjw
brace-expansion Regular Expression Denial of Service vulnerability - https://github.com/advisories/GHSA-v6h2-p8h4-qcjw
brace-expansion: Zero-step sequence causes process hang and memory exhaustion - https://github.com/advisories/GHSA-f886-m6hf-6m8v
brace-expansion: Zero-step sequence causes process hang and memory exhaustion - https://github.com/advisories/GHSA-f886-m6hf-6m8v
fix available via `npm audit fix`
node_modules/brace-expansion
node_modules/jake/node_modules/brace-expansion
node_modules/rimraf/node_modules/brace-expansion

cookie  <0.7.0
cookie accepts cookie name, path, and domain with out of bounds characters - https://github.com/advisories/GHSA-pxg6-pf52-xh8x
fix available via `npm audit fix --force`
Will install iobroker.web@6.3.1, which is a breaking change
node_modules/engine.io/node_modules/cookie
  engine.io  1.8.0 - 6.6.1
  Depends on vulnerable versions of cookie
  Depends on vulnerable versions of debug
  node_modules/engine.io
    socket.io  1.0.0-pre - 3.0.4
    Depends on vulnerable versions of debug
    Depends on vulnerable versions of engine.io
    Depends on vulnerable versions of socket.io-client
    node_modules/socket.io
      iobroker.socketio  3.0.0 - 3.0.13 || 3.1.3 - 3.1.5 || 4.1.0 - 5.0.2 || 6.1.0 - 6.5.7 || >=6.6.0
      Depends on vulnerable versions of @iobroker/webserver
      Depends on vulnerable versions of socket.io
      node_modules/iobroker.socketio
        iobroker.web  4.2.1 - 4.3.0 || >=5.2.3
        Depends on vulnerable versions of @iobroker/webserver
        Depends on vulnerable versions of iobroker.socketio
        Depends on vulnerable versions of iobroker.ws
        node_modules/iobroker.web

debug  <=2.6.8 || 4.0.0 - 4.3.0
Severity: high
debug Inefficient Regular Expression Complexity vulnerability - https://github.com/advisories/GHSA-9vvw-cc9w-f27h
Regular Expression Denial of Service in debug - https://github.com/advisories/GHSA-gxpj-cx7g-858c
Regular Expression Denial of Service in debug - https://github.com/advisories/GHSA-gxpj-cx7g-858c
Depends on vulnerable versions of ms
fix available via `npm audit fix --force`
Will install iobroker.discovery@0.4.0, which is a breaking change
node_modules/engine.io/node_modules/debug
node_modules/mdns-discovery/node_modules/debug
node_modules/socket.io-parser/node_modules/debug
node_modules/socket.io/node_modules/debug
  mdns-discovery  >=0.0.4
  Depends on vulnerable versions of debug
  Depends on vulnerable versions of dns-packet
  node_modules/mdns-discovery
    iobroker.discovery  *
    Depends on vulnerable versions of mdns-discovery
    Depends on vulnerable versions of node-ssdp
    node_modules/iobroker.discovery
  socket.io-parser  <=3.3.4 || 3.4.0 - 4.0.2
  Depends on vulnerable versions of debug
  node_modules/socket.io-client/node_modules/socket.io-parser
  node_modules/socket.io-parser

esbuild  <=0.24.2
Severity: moderate
esbuild enables any website to send any requests to the development server and read the response - https://github.com/advisories/GHSA-67mh-4wv8-2f99
fix available via `npm audit fix --force`
Will install iobroker.js-controller@7.1.1, which is outside the stated dependency range
node_modules/esbuild
  @alcalzone/esbuild-register  *
  Depends on vulnerable versions of esbuild
  node_modules/@alcalzone/esbuild-register
    iobroker.js-controller  >=1.2.1
    Depends on vulnerable versions of @alcalzone/esbuild-register
    Depends on vulnerable versions of tar
    node_modules/iobroker.js-controller

fast-xml-parser  5.0.0 - 5.5.6
Severity: high
fast-xml-parser affected by numeric entity expansion bypassing all entity expansion limits (incomplete fix for CVE-2026-26278) - https://github.com/advisories/GHSA-8gc5-j5rx-235r
Entity Expansion Limits Bypassed When Set to Zero Due to JavaScript Falsy Evaluation in fast-xml-parser - https://github.com/advisories/GHSA-jp2q-39xq-3w4g
fix available via `npm audit fix`
node_modules/fast-xml-parser

form-data  <2.5.4
Severity: critical
form-data uses unsafe random function in form-data for choosing boundary - https://github.com/advisories/GHSA-fjxv-7rqg-78g4
fix available via `npm audit fix --force`
Will install iobroker.backitup@0.2.7, which is a breaking change
node_modules/request/node_modules/form-data
  request  *
  Depends on vulnerable versions of form-data
  Depends on vulnerable versions of qs
  Depends on vulnerable versions of tough-cookie
  node_modules/request
    dropbox-v2-api  *
    Depends on vulnerable versions of request
    node_modules/dropbox-v2-api
      iobroker.backitup  >=0.3.0
      Depends on vulnerable versions of dropbox-v2-api
      node_modules/iobroker.backitup
    request-promise-core  *
    Depends on vulnerable versions of request
    node_modules/request-promise-core
      @cypress/request-promise  *
      Depends on vulnerable versions of request-promise-core
      node_modules/@cypress/request-promise
        node-telegram-bot-api  >=0.64.0
        Depends on vulnerable versions of @cypress/request-promise
        node_modules/node-telegram-bot-api
          iobroker.telegram  >=2.1.0
          Depends on vulnerable versions of @iobroker/webserver
          Depends on vulnerable versions of node-telegram-bot-api
          node_modules/iobroker.telegram

glob  10.2.0 - 10.4.5
Severity: high
glob CLI: Command injection via -c/--cmd executes matches with shell:true - https://github.com/advisories/GHSA-5j98-mcp5-4vw2
fix available via `npm audit fix`
node_modules/glob

ip  *
Severity: high
ip SSRF improper categorization in isPublic - https://github.com/advisories/GHSA-2p57-rm9w-gvfp
fix available via `npm audit fix --force`
Will install iobroker.discovery@0.4.0, which is a breaking change
node_modules/ip
  dns-packet  <=5.2.4
  Depends on vulnerable versions of ip
  node_modules/dns-packet
  node-ssdp  >=1.0.1
  Depends on vulnerable versions of ip
  node_modules/node-ssdp

lodash  <=4.17.23
Severity: high
Command Injection in lodash - https://github.com/advisories/GHSA-35jh-r3h4-6jhm
Regular Expression Denial of Service (ReDoS) in lodash - https://github.com/advisories/GHSA-29mw-wpgm-hmr9
Lodash has Prototype Pollution Vulnerability in `_.unset` and `_.omit` functions - https://github.com/advisories/GHSA-xxjr-mmjv-4gpg
lodash vulnerable to Code Injection via `_.template` imports key names - https://github.com/advisories/GHSA-r5fr-rjxr-66jc
lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and `_.omit` - https://github.com/advisories/GHSA-f23m-r3pf-42rh
fix available via `npm audit fix --force`
Will install iobroker.simple-api@2.8.0, which is a breaking change
node_modules/lodash
node_modules/oauth2-server/node_modules/lodash
  oauth2-server  <=3.1.1
  Depends on vulnerable versions of lodash
  node_modules/oauth2-server
    @iobroker/webserver  >=1.1.0
    Depends on vulnerable versions of oauth2-server
    node_modules/@iobroker/webserver
      iobroker.admin  >=7.5.0
      Depends on vulnerable versions of @iobroker/webserver
      node_modules/iobroker.admin
      iobroker.lovelace  >=2.2.0
      Depends on vulnerable versions of @iobroker/webserver
      Depends on vulnerable versions of pinyin
      node_modules/iobroker.lovelace
      iobroker.simple-api  >=3.0.0
      Depends on vulnerable versions of @iobroker/webserver
      node_modules/iobroker.simple-api
      iobroker.ws  >=3.0.9
      Depends on vulnerable versions of @iobroker/webserver
      node_modules/iobroker.web/node_modules/iobroker.ws
      node_modules/iobroker.ws

minimatch  <=3.1.3 || 5.0.0 - 5.1.7 || 9.0.0 - 9.0.6
Severity: high
minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern - https://github.com/advisories/GHSA-3ppc-4f35-3m26
minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern - https://github.com/advisories/GHSA-3ppc-4f35-3m26
minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern - https://github.com/advisories/GHSA-3ppc-4f35-3m26
minimatch has ReDoS: matchOne() combinatorial backtracking via multiple non-adjacent GLOBSTAR segments - https://github.com/advisories/GHSA-7r86-cg39-jmmj
minimatch has ReDoS: matchOne() combinatorial backtracking via multiple non-adjacent GLOBSTAR segments - https://github.com/advisories/GHSA-7r86-cg39-jmmj
minimatch has ReDoS: matchOne() combinatorial backtracking via multiple non-adjacent GLOBSTAR segments - https://github.com/advisories/GHSA-7r86-cg39-jmmj
minimatch ReDoS: nested *() extglobs generate catastrophically backtracking regular expressions - https://github.com/advisories/GHSA-23c5-xmqv-rm74
minimatch ReDoS: nested *() extglobs generate catastrophically backtracking regular expressions - https://github.com/advisories/GHSA-23c5-xmqv-rm74
minimatch ReDoS: nested *() extglobs generate catastrophically backtracking regular expressions - https://github.com/advisories/GHSA-23c5-xmqv-rm74
fix available via `npm audit fix`
node_modules/filelist/node_modules/minimatch
node_modules/jake/node_modules/minimatch
node_modules/minimatch
node_modules/readdir-glob/node_modules/minimatch
node_modules/rimraf/node_modules/minimatch

ms  <2.0.0
Severity: moderate
Vercel ms Inefficient Regular Expression Complexity vulnerability - https://github.com/advisories/GHSA-w9mr-4mfr-499f
fix available via `npm audit fix --force`
Will install iobroker.discovery@0.4.0, which is a breaking change
node_modules/mdns-discovery/node_modules/ms

multer  <=2.1.0
Severity: high
Multer vulnerable to Denial of Service via incomplete cleanup - https://github.com/advisories/GHSA-xf7r-hgr6-v32p
Multer vulnerable to Denial of Service via resource exhaustion - https://github.com/advisories/GHSA-v52c-386h-88mc
Multer Vulnerable to Denial of Service via Uncontrolled Recursion - https://github.com/advisories/GHSA-5528-5vmv-3xc2
fix available via `npm audit fix`
node_modules/multer

node-forge  <=1.3.3
Severity: high
Forge has a basicConstraints bypass in its certificate chain verification (RFC 5280 violation) - https://github.com/advisories/GHSA-2328-f5f3-gj25
Forge has signature forgery in Ed25519 due to missing S > L check - https://github.com/advisories/GHSA-q67f-28xg-22rw
Forge has Denial of Service via Infinite Loop in BigInteger.modInverse() with Zero Input - https://github.com/advisories/GHSA-5m6q-g25r-mvwx
Forge has signature forgery in RSA-PKCS due to ASN.1 extra field   - https://github.com/advisories/GHSA-ppp5-5v6c-4jwp
fix available via `npm audit fix`
node_modules/node-forge


parseuri  <2.0.0
Severity: moderate
parse-uri Regular expression Denial of Service (ReDoS) - https://github.com/advisories/GHSA-6fx8-h7jm-663j
fix available via `npm audit fix --force`
Will install iobroker.web@6.3.1, which is a breaking change
node_modules/parseuri
  engine.io-client  1.0.2 - 6.1.1
  Depends on vulnerable versions of parseuri
  node_modules/engine.io-client
  socket.io-client  1.0.0-pre - 4.4.1
  Depends on vulnerable versions of engine.io-client
  Depends on vulnerable versions of parseuri
  node_modules/socket.io-client

path-to-regexp  <=0.1.12 || 8.0.0 - 8.3.0
Severity: high
path-to-regexp vulnerable to Regular Expression Denial of Service via multiple route parameters - https://github.com/advisories/GHSA-37ch-88jc-xwx2
path-to-regexp vulnerable to Denial of Service via sequential optional groups - https://github.com/advisories/GHSA-j3q9-mxjg-w52f
path-to-regexp vulnerable to Regular Expression Denial of Service via multiple wildcards - https://github.com/advisories/GHSA-27v5-c462-wpq7
fix available via `npm audit fix`
node_modules/path-to-regexp
node_modules/router/node_modules/path-to-regexp
  express  4.0.0-rc1 - 4.21.2 || 5.0.0-alpha.1 - 5.0.1
  Depends on vulnerable versions of body-parser
  Depends on vulnerable versions of path-to-regexp
  Depends on vulnerable versions of qs
  node_modules/express

picomatch  <=2.3.1
Severity: high
Picomatch: Method Injection in POSIX Character Classes causes incorrect Glob Matching - https://github.com/advisories/GHSA-3v7f-55p6-f55p
Picomatch has a ReDoS vulnerability via extglob quantifiers - https://github.com/advisories/GHSA-c2c7-rcm5-vvqj
fix available via `npm audit fix`
node_modules/picomatch

qs  <=6.14.1
Severity: moderate
qs's arrayLimit bypass in comma parsing allows denial of service - https://github.com/advisories/GHSA-w7fw-mjwx-w883
qs's arrayLimit bypass in its bracket notation allows DoS via memory exhaustion - https://github.com/advisories/GHSA-6rw7-vpxm-498p
fix available via `npm audit fix --force`
Will install iobroker.backitup@0.2.7, which is a breaking change
node_modules/iobroker.simple-api/node_modules/qs
node_modules/qs
node_modules/request/node_modules/qs
  body-parser  1.19.0 - 1.20.3 || 2.0.0-beta.1 - 2.0.2
  Depends on vulnerable versions of qs
  node_modules/body-parser



tar  <=7.5.10
Severity: high
node-tar Vulnerable to Arbitrary File Creation/Overwrite via Hardlink Path Traversal - https://github.com/advisories/GHSA-34x7-hfp2-rc4v
node-tar is Vulnerable to Arbitrary File Overwrite and Symlink Poisoning via Insufficient Path Sanitization - https://github.com/advisories/GHSA-8qq5-rm4j-mr97
Arbitrary File Read/Write via Hardlink Target Escape Through Symlink Chain in node-tar Extraction - https://github.com/advisories/GHSA-83g3-92jg-28cx
tar has Hardlink Path Traversal via Drive-Relative Linkpath - https://github.com/advisories/GHSA-qffp-2rhf-9h96
node-tar Symlink Path Traversal via Drive-Relative Linkpath - https://github.com/advisories/GHSA-9ppj-qmqm-q256
Race Condition in node-tar Path Reservations via Unicode Ligature Collisions on macOS APFS - https://github.com/advisories/GHSA-r6q2-hw4h-h46w
fix available via `npm audit fix --force`
Will install iobroker.lovelace@4.1.15, which is a breaking change
node_modules/tar
  @mapbox/node-pre-gyp  <=1.0.11
  Depends on vulnerable versions of tar
  node_modules/@mapbox/node-pre-gyp
    nodejieba  >=2.5.2
    Depends on vulnerable versions of @mapbox/node-pre-gyp
    node_modules/nodejieba
      pinyin  >=2.11.0
      Depends on vulnerable versions of nodejieba
      node_modules/pinyin

tmp  <=0.2.3
tmp allows arbitrary temporary file / directory write via symbolic link `dir` parameter - https://github.com/advisories/GHSA-52f5-9888-hmc6
No fix available
node_modules/external-editor/node_modules/tmp
  external-editor  >=1.1.1
  Depends on vulnerable versions of tmp
  node_modules/external-editor
    inquirer  3.0.0 - 8.2.6 || 9.0.0 - 9.3.7
    Depends on vulnerable versions of external-editor
    node_modules/inquirer-autosubmit-prompt/node_modules/inquirer
    node_modules/listr-input/node_modules/inquirer
      inquirer-autosubmit-prompt  *
      Depends on vulnerable versions of inquirer
      node_modules/inquirer-autosubmit-prompt
        listr-input  *
        Depends on vulnerable versions of inquirer
        Depends on vulnerable versions of inquirer-autosubmit-prompt
        node_modules/listr-input
          np  >=2.17.0
          Depends on vulnerable versions of listr-input
          node_modules/np
            iobroker.vis-inventwo  *
            Depends on vulnerable versions of np
            node_modules/iobroker.vis-inventwo

tough-cookie  <4.1.3
Severity: moderate
tough-cookie Prototype Pollution vulnerability - https://github.com/advisories/GHSA-72xf-g2v4-qvf3
fix available via `npm audit fix --force`
Will install iobroker.backitup@0.2.7, which is a breaking change
node_modules/tough-cookie

undici  7.0.0 - 7.23.0
Severity: high
Undici has an unbounded decompression chain in HTTP responses on Node.js Fetch API via Content-Encoding leads to resource exhaustion - https://github.com/advisories/GHSA-g9mf-h72j-4rw9
Undici: Malicious WebSocket 64-bit length overflows parser and crashes the client - https://github.com/advisories/GHSA-f269-vfmq-vjvj
Undici has an HTTP Request/Response Smuggling issue - https://github.com/advisories/GHSA-2mjp-6q6p-2qxm
Undici has Unbounded Memory Consumption in WebSocket permessage-deflate Decompression - https://github.com/advisories/GHSA-vrm6-8vpv-qv8q
Undici has Unhandled Exception in WebSocket Client Due to Invalid server_max_window_bits Validation - https://github.com/advisories/GHSA-v9p9-hfj2-hcw8
Undici has CRLF Injection in undici via `upgrade` option - https://github.com/advisories/GHSA-4992-7rv2-5pvq
fix available via `npm audit fix`
node_modules/undici

yaml  1.0.0 - 1.10.2 || 2.0.0 - 2.8.2
Severity: moderate
yaml is vulnerable to Stack Overflow via deeply nested YAML collections - https://github.com/advisories/GHSA-48c2-rrv3-qjmp
yaml is vulnerable to Stack Overflow via deeply nested YAML collections - https://github.com/advisories/GHSA-48c2-rrv3-qjmp
fix available via `npm audit fix`
node_modules/cosmiconfig/node_modules/yaml
node_modules/yaml

61 vulnerabilities (10 low, 17 moderate, 31 high, 3 critical)

To address issues that do not require attention, run:
  npm audit fix

To address all issues possible (including breaking changes), run:
  npm audit fix --force

Some issues need review, and may require choosing
a different dependency.

Das sind die möglichen Severities
null, "info", "low", "moderate", "high", "critical", or "none"

Wie ihr seht sind da einige Severity=high dabei. Wäre das dann schon kritisch um eine Installation abzubrechen? Wahrscheinlich nicht.

Es gibt 2 criticals, aber wer bewertet, ob dann die Installation abgebrochen werden soll. ggfs blockiert der Fehler dann auch längers den Update, da der maintainer das einfach nicht fixen will.

Nur soviel dazu, das man wahrscheinlich nix extra erfinden muss, weil es schon da ist.
Ggfs kann man auch mal bei anderen großen js/node Projekten schauen, bei denen viel mit Adapter/Plugins/etc. nachladbarer Funktionalität gearbeitet wird
(obwohl es betrifft ja auch sub und sub/sub dependencies, bei denen sich ein Problem einstellen kann)

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 17:41:21 GMT

Thomas Braun — Thu, 09 Apr 2026 17:41:21 GMT

Ich hab gerade nochmal geschaut. Also nach meinem Dafürhalten sollte der in iob diag integrierte Test:
https://github.com/nodejs/is-my-node-vulnerable
auch sowas wie die axios-Geschichte abdecken. Es wird tagesaktuell die CVS-Datenbank abgefragt:

This directory contains two lists of disclosed vulnerabilities:
core: Vulnerabilities affecting Node.js core
npm: Vulnerabilities affecting third party modules

Mit third party modules müsste dann ja auch z.B. axios und damals color oder wie das manipulierte Modul auch noch gleich hieß mitgefangen werden. Sollte man das nicht auch in den admin implementieren und alle 24 oder 48 Stunden ausführen lassen? Ausgabe dann im Log.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 17:30:36 GMT

mcm1957 — Thu, 09 Apr 2026 17:30:36 GMT

@Jey-Cee sagte:

@mcm1957 sagte:

Und dann wär noch zu klären wer denn die User bei einem Alarm betreuen / beraten will ...

Ich Denke das ist Schritt drei, Schritt eins sollte sein Installation blocken, Schritt zwei betroffene Pakete löschen und weitere Maßnahmen.

Allerdings ist das ein erheblicher Aufwand und bedarf permanenter und Zeit naher Betreuung des entsprechenden Moduls.
So etwas mit rein zu nehmen macht m.E. Sinn, wenn möglich sollte hier aber auf eine Lösung gesetzt werden die Eigenständig ist und von mehreren Projekten genutzt wird.

Installation blocken wird schwer - dazu müsstest du npm ändern...
Es geht ja nicht drum den Adapter @1.2.3 zu blocken sondern um dependencies. Und die bewertet ioBroker nicht. Die Auflösung erfolgt durch npm. ioBroker setzt nur 'npm i adapter@xxx' ab - alles andere erledigt npm. Da kann ioBroker also kaum was blocken.

Löschen von Paketen wär auch hoch riskant. Das wär ein schönen DOS Tool. Ich würde dringend davon abraten einfach mal so Löschaktionen zentral auszulösen. Außerdem hätte das z.B. beim letzten Axios genau nix geholfen - außer das User nicht mehr gesehen hätten dass das schadhafte Paket installiert war.

Denkbar ist m.E. nur eine Warnfunktion. Alles andere stufe ich als riskant ein. Da würde ioBroker selbst ggF zu einer Schadensquelle.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 12:07:46 GMT

Jey Cee — Thu, 09 Apr 2026 12:07:46 GMT

@mcm1957 sagte:

Und dann wär noch zu klären wer denn die User bei einem Alarm betreuen / beraten will ...

Ich Denke das ist Schritt drei, Schritt eins sollte sein Installation blocken, Schritt zwei betroffene Pakete löschen und weitere Maßnahmen.

Allerdings ist das ein erheblicher Aufwand und bedarf permanenter und Zeit naher Betreuung des entsprechenden Moduls.
So etwas mit rein zu nehmen macht m.E. Sinn, wenn möglich sollte hier aber auf eine Lösung gesetzt werden die Eigenständig ist und von mehreren Projekten genutzt wird.

Reply to iobroker.securitycheck --- Brainstorming on Thu, 09 Apr 2026 09:15:51 GMT

mcm1957 — Thu, 09 Apr 2026 09:15:51 GMT

-> Sprecht es ev. im Meeting an.

Persönlich denke ich sollte sowas von js-controller oder admin erledigt werden. Ein eigener Adapter ist da eher Overkill.

Zu klären wäre auch was denn genau und wie gecheckt werden soll. Eine Liste von blacklisted Packages? OK, die könnte jederzeit analog zu den Repos gefetched und abgeglichen werden. Ginge sogar bei jeder Installation zusätzlich zu regelmäßigem Scan.

Echten "Code" / Scripts würd ich keinesfalls dynamisch von irgendwo laden. Da ist das Risiko m.E. zu groß dass wir dann selbst Schadcode installieren.

Und einen Virenscanner kann das nie ersetzen. Code der nicht als npm Package rumliegt zu scannen macht wenig Sinn.

Und dann wär noch zu klären wer denn die User bei einem Alarm betreuen / beraten will ...

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 19:22:45 GMT

Homoran — Wed, 08 Apr 2026 19:22:45 GMT

@Feuersturm sagte:

Du kannst das Thema ja hier heraustrennen :)

Erledigt

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 19:17:47 GMT

Feuersturm — Wed, 08 Apr 2026 19:17:47 GMT

@Homoran sagte:

Wird langsam OT!

Du kannst das Thema ja hier heraustrennen :)

Das User Meldungen ignorieren, wird man nicht verhindern können. Wenn sich jemand aber durch ein Adapter Update korrumpierte Pakete unwissentlich einfängt, dann wäre eine Benachrichtigung schon was feines. Die Anzahl der Angriffe auf npm Pakete wird in der Zukunft sicherlich nicht weniger werden ;-)

Die wenigsten Enduser wird man mit den hier im Forum geposteten Skripten erreichen, wenn es mal wieder schadhafte npm Pakete gibt

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 19:11:06 GMT

Homoran — Wed, 08 Apr 2026 19:11:06 GMT

Wird langsam OT!
Auch wenn sehr interessant und wichtig ist

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 19:14:34 GMT

Thomas Braun — Wed, 08 Apr 2026 19:14:34 GMT

@Feuersturm

Eigentlich müsste sowas als Komponente in den js-controller rein.
Bleibt aber das Problem, das Benachrichtigungen z. B. bezüglich der nach außen offenen Ports auch heute schon gekonnt ignoriert werden.
Keine Ahnung was da die 'Denke' ist. Mein kleines System findet schon keiner? Das ist aber eine ganz große Fehlannahme...

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 19:09:32 GMT

Homoran — Wed, 08 Apr 2026 19:09:32 GMT

@Feuersturm oder noch besser im admin integriert, dann kann niemand "diesen Blödsinn" löschen

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 19:06:38 GMT

Feuersturm — Wed, 08 Apr 2026 19:06:38 GMT

@Thomas-Braun sagte:

Diese Ignoranten werden sich bestimmt keinen solchen Adapter installieren.

Oder es ist ein Adapter der zur Basisinstallation dazugehört und immer mit installiert wird (ähnlich wie Backitup)

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 18:59:16 GMT

Homoran — Wed, 08 Apr 2026 18:59:16 GMT

@Thomas-Braun sagte:

iobroker.securitycheck oder so. Da könnte man dann alles mögliche bündeln.

Ja so etwas schwebte mir vor.
Nicht für die Ignoranten, sondern für die Interessierten

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 18:58:24 GMT

Thomas Braun — Wed, 08 Apr 2026 18:58:24 GMT

@Homoran

iobroker.securitycheck oder so. Da könnte man dann alles mögliche bündeln. Wobei es ja sowas auch schon zumindest für die nach außen offenen Ports gibt. Aber auch diese Benachrichtigungen werden offenbar geflissentlich ignoriert.
Diese Ignoranten werden sich bestimmt keinen solchen Adapter installieren.

Reply to iobroker.securitycheck --- Brainstorming on Wed, 08 Apr 2026 18:49:31 GMT

Homoran — Wed, 08 Apr 2026 18:49:31 GMT

@Feuersturm das ist eine sehr gute Idee!
Die Frage ist nur für mich, ob so etwas ggf. in einen anderen Adapter gehört.
Quasi Virenscanner für iobroker