{"answers":{"affected":"2 open source packages ship an affected version, including base and toml-reader.","exploited":"There is no known exploitation of HSEC-2023-0007 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"HSEC-2023-0007 is a denial of service vulnerability in base, published on 14 Nov 2025. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for HSEC-2023-0007 and fix it if it is affected.\n\nWhat it is: HSEC-2023-0007 is a denial of service vulnerability in base, published on 14 Nov 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of HSEC-2023-0007 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- base (Hackage): affected from 3.0.3.1; no fix listed\n- toml-reader (Hackage): affected from 0.1.0.0; fixed in 0.2.0.0\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/HSEC-2023-0007/ (Markdown: https://insights.sbomify.com/HSEC-2023-0007/index.md)","id":"HSEC-2023-0007","markdown":"https://insights.sbomify.com/HSEC-2023-0007/index.md","name":"HSEC-2023-0007","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"Haskell numeric library","requires_auth":"none","summary":"Attackers can cause denial of service by providing input with large exponents to Numeric.readFloat, exhausting memory and CPU resources.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"# `readFloat`: memory exhaustion with large exponent\n\n`Numeric.readFloat` takes time and memory linear in the size of the\nnumber _denoted_ by the input string.  In particular, processing a\nnumber expressed in scientific notation with a very large exponent\ncould cause a denial of service.  The slowdown is observable on a\nmodern machine running GHC 9.4.4:\n\n```\nghci\u003e import qualified Numeric\nghci\u003e Numeric.readFloat \"1e1000000\"    -- near instantaneous\n[(Infinity,\"\")]\nghci\u003e Numeric.readFloat \"1e10000000\"   -- perceptible pause\n[(Infinity,\"\")]\nghci\u003e Numeric.readFloat \"1e100000000\"  -- ~ 3 seconds\n[(Infinity,\"\")]\nghci\u003e Numeric.readFloat \"1e1000000000\" -- ~ 35 seconds\n[(Infinity,\"\")]\n```\n\n## In *base*\n\n`Numeric.readFloat` is defined for all `RealFrac a =\u003e a`:\n\n```haskell\nreadFloat :: RealFrac a =\u003e ReadS a\n```\n\nThe `RealFrac` type class does not express any bounds on the size of\nvalues representable in the types for which instances exist, so\nbounds checking is not possible (in this *generic* function).\n`readFloat` uses to `Text.Read.Lex.numberToRational` which, among\nother things, calculates `10 ^ exponent`, which seems to take linear\ntime and memory.\n\n**Mitigation:** use `read`.  The `Read` instances for `Float` and\n`Double` perform bounds checks on the exponent, via\n`Text.Read.Lex.numberToRangedRational`.\n\n## In *toml-reader*\n\nThe issue was detected in *toml-reader* version 0.1.0.0, and\nmitigated in version 0.2.0.0 by immediately returning `Infinity`\nwhen the exponent is large enough that there's no reason to process\nit.","ecosystems":["Hackage"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"readFloat: memory exhaustion with large exponent","id":"HSEC-2023-0007","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2025"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"Hackage","fixed":[],"introduced":["3.0.3.1"],"last_affected":[],"package":"base","purl":"pkg:hackage/base","source":"HSEC-2023-0007"},{"ecosystem":"Hackage","fixed":["0.2.0.0"],"introduced":["0.1.0.0"],"last_affected":[],"package":"toml-reader","purl":"pkg:hackage/toml-reader","source":"HSEC-2023-0007"}],"products":null,"published":"2025-11-14","related":[],"sources":[{"class":"open","licence":"CC0 1.0","name":"Haskell Security Response Team","prefix":"HSEC"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers can cause denial of service by providing input with large exponents to Numeric.readFloat, exhausting memory and CPU resources.","url":"https://insights.sbomify.com/HSEC-2023-0007/"}