---
title: "Comment by jahanzaib12 on \"BrunnerCTF - php-2003 Writeup\" | Hashnode"
description: "The interesting part here is how several small validation weaknesses have to line up before the deserialization issue becomes useful. The Unicode soft-hyphen by"
url: "https://hashnode.com/posts/brunnerctf-php-2003-writeup/6a8b0bd013d6c9e2a997446f/comment/6a8fb5afea05c087ba62a034"
---

[Discussion](https://hashnode.com/posts/brunnerctf-php-2003-writeup/6a8b0bd013d6c9e2a997446f)

Comment [BrunnerCTF - php-2003 Writeup](https://hashnode.com/posts/brunnerctf-php-2003-writeup/6a8b0bd013d6c9e2a997446f)

[jahanzaib12](https://hashnode.com/@jahanzaib12)

[Aug 27](https://hashnode.com/posts/brunnerctf-php-2003-writeup/6a8b0bd013d6c9e2a997446f/comment/6a8fb5afea05c087ba62a034)

The interesting part here is how several small validation weaknesses have to line up before the deserialization issue becomes useful. The Unicode soft-hyphen bypass and the loose `!=` comparison are good examples of why validation needs to match the actual application logic.

The duplicate-property trick is probably the most interesting part, since the application's regex sees `role=request` while PHP ultimately ends up with `role=admin`. It shows how validating a serialized representation without considering how PHP will interpret it can be dangerous.

Overall, the write-up does a nice job of showing that the vulnerability wasn't just `unserialize()` itself. The surrounding validation checks also played an important role in the exploit chain.