How do you best mitigate HSEC-2026-0007?

Learn
1

I rely on http-api-data, and it is not compatible with text-iso8601-0.2. phadej has said that an upcoming release will be compatible: Relax upper bound for text-iso8601 to 0.3 by dancewithheart · Pull Request #161 · fizruk/http-api-data · GitHub

But for now, what is the risk in allowing the newer version of text-iso8601 (overriding the bounds)? It seems to me that the risk of anything breaking when overriding the bounds isn’t that big. Not when considering that the DoS vulnerability should then be solved.

This works:

http-api-data-0.7 $ cabal test -w ghc-9.14.1 \
   -c 'text-iso8601>=0.2' \
   --allow-newer=http-api-data:text-iso8601,http-api-data:quickcheck-instances,http-api-data:QuickCheck \
   --enable-tests
2

If you are shipping or operating any web service that exposes an endpoint using this.. that service and possibly others on the same machine, can be crashed at will by a crafted request, if I understand rightly ?

3

Yes. While I haven’t verified, it looks like a terrible vulnerability. It’s a shame this important package hasn’t been updated, since Stackage LTS 25 is going to be released soon. It likely means that many users will be vulnerable for another year.

4

But for now, what is the risk in allowing the newer version of text-iso8601 (overriding the bounds)?

I did exactly this in a couple of large projects and AFAIK nothing broke.

5

It shouldn’t be necessary to override bounds anymore, because the Stackage Nightly now has aeson with the backported fix:

See