I don't have a Proof of Concept yet, but to me it seems that the following pieces of code:

    "https?://registry.npmjs.*/.*",
    "https?://(www\\.)?npmjs.*/package.*",
    "https?://.+python.+org/(packages|project)/.*",

nuget_www_pattern = r"^https?://.*nuget.org/(api/v2/)?packages?/(?P<name>.+)/(?P<version>.+)$"

@purl_router.route("https?://.*sourceforge.net/projects?/.*")

could accidentally match on domains like registry.npmjs.evil.com, malware.python.evil.org, evilnuget.org or evilsourceforge.net as well. If someone relies on this package to confirm whether a package URL is from a trusted source (doesn't sound like its intended purpose, but you never know what people do with your library), they could be fooled by malicious domains like these and download malware instead.

A bit harder would be to abuse regexes like

    r"https?://raw.githubusercontent.com/(?P<namespace>[^/]+)/(?P<name>[^/]+)/"

@purl_router.route("https?://api.github\\.com/repos/.*")

    r"^https?://hackage.haskell.org/package/"

    "https?://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/.*"

where an attacker only has a small amount of possible domains (eg. raw_githubusercontent.com, apixgithub.com, hackageehaskell.org, storageggoogleapis.com) which could also match (since the . isn't escaped and treated like a wildcard character)

My recommendation (even if it isn't a security issue right now, but to prevent one in the future) would be to escape these regexes more carefully. Something like (.+\\.)?python\\.org and hackage\\.haskell\\.org