The HTTP session component takes the session id straight from the client-supplied sid cookie. The id validator Session::validID() was inert because it compared the result of preg_match() with !== false: preg_match() returns 1 on match, 0 on no match and false only on an engine error, so the allowlist accepted every string, including one containing path separators and .. segments.
The default file-based session handler (FileHandler) then built the on-disk path by concatenating that attacker-controlled id onto the session directory with no containment (getFilename() used neither basename() nor realpath()). An unauthenticated request carrying Cookie: sid=../../some/path therefore caused the serialized session to be written and any missing parent directories to be created at an arbitrary location outside the configured runtime/session directory.
This arbitrary file write is guaranteed by the framework and requires no cooperation from the application. Because the written bytes are the serialized $_SESSION, an application that stores an attacker-influenced value in the session (a repopulated form field, a search term, a flash message, a username) lets the attacker control part of the file content; writing a .php file into a served directory, or into any file later included as PHP, escalates the write to remote code execution.
The same defect also enables session fixation, since the attacker fully chooses the session id.