vars's mapping proxy can expose internal dictionary even for built-in types

[qexat]

Bug report

Bug description:

By creating a type or class with a definition of __eq__ that simply returns the other object, it is possible to access the underlying dictionary behind the mapping proxy returned by vars.

This can be (ab)used to bypass mutability restrictions on built-in types, as the example below shows:

class Evil:
    def __eq__(self, other):
        return other

# less readable version of Evil:
# type("Evil", (), {"__eq__": lambda self, other: other})

# this statement adds a method `prepend` to the built-in type `list`
# 1. vars(list) == Evil() returns the underlying dictionary of `list`
# 2. we can then use the dict[name] = value statement to set the attribute `name`
(vars(list) == Evil())["prepend"] = lambda self, value: self.insert(0, value)

x = [3, 5, 2]
x.prepend(7)

print(x)  # [7, 3, 5, 2]

This can be used to cause a segmentation fault:

# reusing Evil from earlier
(vars(type) == Evil())["__instancecheck__"] = lambda *_: False
# fish: Job 1, 'python' terminated by signal SIGSEGV

No FFI, not a single line of C code required.

This also works on CPython 2.7 and 3.9. It might even be possible to do on even earlier versions.

Disclaimer
I have independently discovered this by myself (no LLM).

CPython versions tested on:

3.14, 3.12, 3.11

Operating systems tested on:

Linux

Linked PRs

• gh-152405: Prevent mappingproxy operator dispatch from exposing underlying mappings #152449

[zainnadeem786]

Hi @qexat @sobolevn

I investigated this on current main and was able to reproduce both the dictionary exposure and built-in type mutation behavior.

The root cause appears to be in mappingproxy_richcompare(). During comparison, it delegates directly with the proxied mapping as the left operand:

PyObject_RichCompare(v->mapping, w, op)

For a non-dict RHS, the dict comparison returns NotImplemented, after which generic rich comparison can call the reflected comparison on the RHS with the raw underlying dict. A user-defined __eq__ can therefore receive and return the internal dictionary.

I also found a sibling issue in the mappingproxy union path. mappingproxy_or() similarly unwraps the proxy and passes the raw mapping into PyNumber_Or(), allowing __ror__ on the RHS to receive the underlying dict.

Minimal repros:

class Evil:
    def __eq__(self, other):
        return other

leaked = vars(list) == Evil()
print(type(leaked))  # dict

class EvilRor:
    def __ror__(self, other):
        return other

leaked = vars(list) | EvilRor()
print(type(leaked))  # dict

I confirmed that the leaked dict can mutate a built-in type dictionary, and I was also able to reproduce a crash in a subprocess after mutating and then removing an attribute from list.__dict__.

This seems related to the older MappingProxyType encapsulation discussions such as GH-88004 / bpo-43838 and GH-88762. Based on that prior direction, a copy-backed delegation approach for rich comparison and union seems like the safest option because it avoids passing proxy->mapping to arbitrary user code while preserving existing comparison behavior better than simply returning NotImplemented.

For completeness, I reproduced this on a locally built CPython debug interpreter (python_d.exe) from the latest main. After mutating the leaked built-in type dictionary through the exposed mapping, the subprocess terminated with a Windows access violation. The attached screenshot shows the resulting crash dialog and serves as supporting evidence alongside the textual reproduction.

I’m going to prepare a focused PR with regression tests unless there is a preferred different direction.