Hello, I have a few questions about your PR :
Could you please use the default template ?
Could you also give me a context, in iTop, where this could happen ? Look like this PR is global, not for iTop (where the context can maybe make it useless), so I'd appreciate that you can give us more details, thank you in advance
For example, $escapedDotOutput = escapeshellarg($sImageFilePath); seems useless since it's built with methods like utils::GetDataPath() that doesn't come from the user. Or maybe I missed something, like a different way to bypass it ?

Hello, I have a few questions about your PR : Could you please use the default template ? Could you also give me a context, in iTop, where this could happen ? Look like this PR is global, not for iTop (where the context can maybe make it useless), so I'd appreciate that you can give us more details, thank you in advance For example, $escapedDotOutput = escapeshellarg($sImageFilePath); seems useless since it's built with methods like utils::GetDataPath() that doesn't come from the user. Or maybe I missed something, like a different way to bypass it ?

Hi @jf-cbd, thank you for the review! Let me address your questions:

Context where these issues could occur in iTop:

1. Graphviz command injection (graphviz.php)

You're correct that $sImageFilePath is built internally via utils::GetDataPath(). However, $sDotExecutable comes from:

$sDotExecutable = MetaModel::GetConfig()->Get('graphviz_path');

This config value could potentially contain unexpected characters if:

• An administrator with config access (but not necessarily full server access) sets a malicious or improperly formatted path
• The config file is modified by another vulnerability or misconfiguration
• A compromised extension or module modifies the config

While the risk is lower since it requires config-level access, using escapeshellarg() provides defense-in-depth and follows secure coding best practices for any external command execution.

If you prefer, I can:

• Remove the escaping for $sImageFilePath (since it's internally generated)
• Keep only $sDotExecutable and $sDotFilePath escaped
• Update the PR description to clarify the actual attack surface

2. DBSearch::unserialize validation (dbsearch.class.php)

This is called from multiple user-facing endpoints that accept serialized filter parameters:

• ajax.render.php (operations: 'ajax', 'pie_chart', 'chart') - lines 617, 656, 712, 343
• UI.php (multiple filter operations) - lines 530, 732, 782, 833, 860, 1054, 1573, 1604, 1630
• run_query.php - line 127
• tagadmin.php - line 87

Example attack scenario:

1. User sends a crafted request to pages/ajax.render.php?operation=ajax&filter=<malformed_payload>
2. Without validation, malformed JSON structures or extremely large payloads could cause unexpected behavior
3. The added checks reject invalid structures early with a clear error

Current code path:

$sFilter = utils::ReadParam('filter', '', false, 'raw_data');
$oFilter = DBSearch::unserialize($sFilter); // User-controlled input

The validation ensures the decoded payload has the expected structure before processing.

Re: Default PR template

Could you point me to the template location? I'll update the PR description to follow it.

Proposed action:

Would you prefer I:

1. Simplify the graphviz fix - only escape $sDotExecutable (the config value) and $sDotFilePath, remove $sImageFilePath escaping?
2. Keep the DBSearch validation as-is (addresses real user input)?
3. Update PR description with the template and more specific context?

Let me know and I'll update accordingly. Thanks for the careful review!

@nikunj-kohli The template was already linked to by @jf-cbd: https://github.com/Combodo/iTop/blob/develop/.github/pull_request_template.md

Please don't use AI to generate PRs, replies and code changes, it puts more burden on maintainers and doesn't help. It is the opposite of helping out and against rules of #Hacktoberfest. Especially these last lines give it away, since that was what the AI agent told You to do, it was not ment to paste this in the PR description:

Rollback / mitigation

• Reverting the commit(s) restores previous behavior. Both changes are isolated and low-risk; if maintainers prefer a different validation policy for DBSearch::unserialize() we can tune the checks or extract validation into a helper for easier adjustment.

Suggested commit message

• security: escape Graphviz exec args and validate DBSearch::unserialize input

  • Escape shell args when running dot to avoid injection; add structure/type/length checks in DBSearch::unserialize() to reject malformed or oversized filter payloads.

Suggested reviewers / labels

• reviewers: core-maintainers, security-team
• labels: security, bug, quickfix

Optional git commands (PowerShell) to create branch, commit and push (copy/paste locally)

git checkout -b fix/graphviz-escape-dbsearch-unserialize-validation
git add pages/graphviz.php core/dbsearch.class.php
git commit -m "security: escape Graphviz exec args and validate DBSearch::unserialize input"
git push --set-upstream origin fix/graphviz-escape-dbsearch-unserialize-validation

Notes / next steps I can take after you open the PR

• Prepare a concise PR checklist (CI steps, manual checks) and a short unit/regression test or example request for maintainers.
• If maintainers accept, proceed to the next item in the queue: mitigate or replace eval() usage in renderer JS (high priority), or progressively harden unserialize call sites (wrap with try/catch and reject request filters explicitly).

@nikunj-kohli The template was already linked to by @jf-cbd: https://github.com/Combodo/iTop/blob/develop/.github/pull_request_template.md

Please don't use AI to generate PRs, replies and cod, it puts more burden on maintainers and doesn't help. It is the opposite of helping out and against rules of #Hacktoberfest. Especially these last lines give it away, since that was what the AI agent told You to do, it was not ment to paste this in the PR description:

Rollback / mitigation

• Reverting the commit(s) restores previous behavior. Both changes are isolated and low-risk; if maintainers prefer a different validation policy for DBSearch::unserialize() we can tune the checks or extract validation into a helper for easier adjustment.

Suggested commit message

• security: escape Graphviz exec args and validate DBSearch::unserialize input

  • Escape shell args when running dot to avoid injection; add structure/type/length checks in DBSearch::unserialize() to reject malformed or oversized filter payloads.

Suggested reviewers / labels

• reviewers: core-maintainers, security-team
• labels: security, bug, quickfix

Optional git commands (PowerShell) to create branch, commit and push (copy/paste locally)

git checkout -b fix/graphviz-escape-dbsearch-unserialize-validation
git add pages/graphviz.php core/dbsearch.class.php
git commit -m "security: escape Graphviz exec args and validate DBSearch::unserialize input"
git push --set-upstream origin fix/graphviz-escape-dbsearch-unserialize-validation

Notes / next steps I can take after you open the PR

• Prepare a concise PR checklist (CI steps, manual checks) and a short unit/regression test or example request for maintainers.
• If maintainers accept, proceed to the next item in the queue: mitigate or replace eval() usage in renderer JS (high priority), or progressively harden unserialize call sites (wrap with try/catch and reject request filters explicitly).

Okay, I'll keep that in my mind. Do you want me to change the format right now or the current one is bearable?

Since this part is the first section of the template, I would say "no, not bearable".

<!--

IMPORTANT: Please follow the guidelines within this PR template before submitting it, it will greatly help us process your PR. 🙏

Any PRs not following the guidelines or with missing information will not be considered.

-->

Unless you want your PR not to be considered..

Since this part is the first section of the template, I would say "no, not bearable".

<!--

IMPORTANT: Please follow the guidelines within this PR template before submitting it, it will greatly help us process your PR. 🙏

Any PRs not following the guidelines or with missing information will not be considered.

-->

Unless you want your PR not to be considered..

Alright, I've made the change in PR Description. You can check and let me know if I'm still making a mistake, thankyou for your review.

Thank you for the changes.
Could you please explain me, with your words, the 3 different "protections" you implemented, and give an example of how to exploit the non-corrected code in iTop ? For example, how to perform the "Example attack scenario" you described ? It seems it's already protected, no ?