fix(x402): validate price input and fail closed on malformed on-chain amounts by bussyjd · Pull Request #771 · ObolNetwork/obol-stack

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd · 2026-07-16T12:22:22Z

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Found by the 2026-07-16 hostile-operator audit (see PR #770), adversarially confirmed. The singular --price/--per-request CLI path is the only price path with no validation (unlike --per-mtok/--per-hour, which validate, and --accept's price=, which rejects negatives), and the on-chain amount conversion discards its parse error.

Impact

obol sell http myapi --price 0,01 --pay-to 0x… --network base (EU comma decimal — an ordinary typo) succeeds, reconciles Ready, and obol sell status prints "Price: 0,01" looking fine. Then in the verifier hot path (resolvePaidRoute → BuildV2RequirementWithAsset → decimalToAtomic):

"0,01" parses 0 and drops the rest → the route silently prices at $0 (free).
"abc", "", "$0.01" → big.Float.Parse returns nil, the error is discarded, and the next Mul(nil, …)panics (nil deref) on every request to that route. A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so both a CLI guard and a library-level guard are required.

Fix (two layers, both fail-closed)

CLI:resolvePriceTable validates --price/--per-request with the existing validate.Price (rejects non-numeric incl. 0,01, and negatives) before building the offer.
Library:decimalToAtomic now returns (string, error) — capturing the parse error, rejecting nil and negative — threaded through BuildV2Requirement/BuildV2RequirementWithAsset. resolvePaidRoute skips an option with a bad price so the route falls through its existing len(reqs)==0 → 403 fail-closed path (never a free or panicking route); the inference gateway propagates the error. A malformed price now denies the route, never serves it free.

Tests: resolvePriceTable rejects 0,01/abc/$0.01/-1/``; decimalToAtomic returns an error (not a panic) on the same; and an end-to-end verifier test proves a `RouteRule{Price:"0,01"}` (simulating a kubectl-applied offer) returns 403, not a free 402. Full `go test ./...` green.

https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

… amounts Root cause: the --price/--per-request singular-price CLI path in resolvePriceTable (cmd/obol/sell.go) had zero validation, unlike the --per-mtok/--per-hour branches. A typo like an EU comma decimal ("0,01") sailed through, and decimalToAtomic (internal/x402/chains.go) discarded big.Float.Parse's error entirely: "0,01" silently parsed as "0" (mispricing the offer at $0), while "abc"/""/"$0.01" left amountFloat nil, panicking the next line's Mul(nil, ...) on every request through the verifier hot path (verifier.go resolvePaidRoute -> BuildV2RequirementWithAsset -> decimalToAtomic). A ServiceOffer applied directly via kubectl bypasses the CLI entirely, so a CLI-only guard isn't sufficient. Fix, two layers, both fail-closed: 1. CLI: resolvePriceTable now validates perRequest with validate.Price before returning it, matching the existing perMTok/perHour branches. 2. Library (defense-in-depth): decimalToAtomic now returns (string, error) instead of panicking on a discarded parse error; BuildV2RequirementWithAsset and BuildV2Requirement propagate the error instead of building a $0/invalid PaymentRequirements. resolvePaidRoute skips an option that fails to build (mirroring its existing "chain not pre-resolved" skip-and-continue pattern); if that leaves zero resolvable options the route already fails closed via the existing len(reqs)==0 -> (nil,false) -> 403 path. inference/gateway.go propagates the error from buildHandler. Confirmed Canary402 proactive-audit finding (critical) on integration/v0.14.0-rc0. Claude-Session: https://claude.ai/code/session_014YjPMViNrZ7zBVgUQzwEKk

bussyjd merged commit 7577b11 into integration/v0.14.0-rc0Jul 16, 2026

Uh oh!

Conversation

bussyjd commented Jul 16, 2026

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Impact

Fix (two layers, both fail-closed)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

bussyjd commented Jul 16, 2026

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Impact

Fix (two layers, both fail-closed)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

bussyjd commented Jul 16, 2026

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Impact

Fix (two layers, both fail-closed)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

bussyjd commented Jul 16, 2026

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Impact

Fix (two layers, both fail-closed)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

bussyjd commented Jul 16, 2026

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Impact

Fix (two layers, both fail-closed)

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

bussyjd commented Jul 16, 2026

Proactive-audit finding (CRITICAL): unvalidated price → mispriced or panicking on-chain amount

Impact