Avoid Arbitrary File Deletion abuse via Object Injection#3874
Avoid Arbitrary File Deletion abuse via Object Injection#3874mcdruid wants to merge 1 commit intogetgrav:developfrom
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting
| try { | ||
| if ($this->tmp === null) { | ||
| $this->tmp = $this->directory . uniqid('', true); | ||
| $this->tmp = $this->directory . uniqid(__CLASS__, true); | ||
| } |
There was a problem hiding this comment.
The new temp filename uses uniqid(__CLASS__, true), but __CLASS__ contains backslashes. On Windows these are treated as path separators, so the prefix Grav\Framework\Cache\Adapter\FileCache... expands into nested directories under $this->directory that are never created. As soon as file_put_contents($this->tmp, $data) runs, cache writes will fail with "No such file or directory" and the cache backend becomes unusable on Windows installations. Consider stripping namespace separators or using a simple prefix like FileCache.
Useful? React with 👍 / 👎.
2 participants
As discussed with @rhukster this simple change should avoid
\Grav\Framework\Cache\Adapter\FileCache::__destructbeing abused via Object Injection to achieve Arbitrary File Deletion.I've used
strposrather thanstr_starts_withas it looks like Grav supports PHP 7.