# PSF-2019-13: ssl.match_hostname() ignores extra string after whitespace in IPv4 address

> Python's ssl.match_hostname incorrectly validates IPv4 addresses with trailing whitespace, potentially bypassing certificate checks in older versions.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 1 Jul 2019

## What is PSF-2019-13?

PSF-2019-13 is a vulnerability, published on 1 Jul 2019. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

``inet_aton()`` accepts trailing characters after a valid IP.  Because of
that, Python ``ssl.match_hostname('1.1.1.1 ; this should not work but does')``
succeeded when it should fail.

The issue was introduced in `bpo-32819
<https://bugs.python.org/issue32819>`_ by `commit aef1283b
<https://github.com/python/cpython/commit/aef1283ba428e33397d87cee3c54a5110861552d>`_.
Only Python 3.7 and newer are affected. It's a potential security bug
although **low severity**. For one Python 3.7 and newer **no longer use**
``ssl.match_hostname()`` to verify hostnames and IP addresses of a
certificate: **matching is performed by OpenSSL**.

It should not possible to register a x509 certificate with a hostname with
spaces.

The glibc function ``inet_aton()`` accepts input as valid if said input is
a IPv4 address followed by zero or more characters that are valid
white-space as decided by ``isspace()``, with the rest of the string after
the first white-space being ignored. As ``'\r'`` is a valid white-space
character the rest of the string is ignored (including the ``'\r'``). See
`glibc bug 24111: Deprecate inet_addr, inet_aton
<https://sourceware.org/bugzilla/show_bug.cgi?id=24111>`_.

## Which versions are affected by PSF-2019-13?


## How do I fix PSF-2019-13?

No fix has been published for PSF-2019-13 yet. Limit exposure of the affected software until one is available.

## Is PSF-2019-13 being exploited?

There is no known exploitation of PSF-2019-13 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for PSF-2019-13 and fix it if it is affected.

What it is: PSF-2019-13 is a vulnerability, published on 1 Jul 2019. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of PSF-2019-13 in the wild and no public exploit code.

Task:
1. 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.
2. 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.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/PSF-2019-13/ (Markdown: https://insights.sbomify.com/PSF-2019-13/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/PSF-2019-13

---
From sbomify Insights: https://insights.sbomify.com/PSF-2019-13/
Summaries are generated and may contain mistakes; the official description above is the record.