Data Injection 2.15.9 crashes with Safe\unserialize error

[DooSys]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

GLPI Version

10.0.8

Plugin version

2.15.9

Bug description

Hi, After upgrading the Data Injection plugin from version 2.15.8 to 2.15.9, opening the Data Injection page triggers a fatal PHP error.

The issue occurs immediately when accessing Data Injection from the GLPI interface.

Downgrading the plugin to 2.15.8 resolves the issue on the same GLPI instance.

The following error is displayed:

Attempted to call function "unserialize" from namespace "Safe".
Did you mean to call "\unserialize"?

In /var/glpi/marketplace/datainjection/front/clientinjection.form.php(44)

#0 ./src/Glpi/Controller/LegacyFileLoadController.php(64): require()
#1 ./vendor/symfony/http-kernel/HttpKernel.php(181): Glpi\Controller\LegacyFileLoadController->__invoke()
#2 ./vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#3 ./vendor/symfony/http-kernel/Kernel.php(208): Symfony\Component\HttpKernel\HttpKernel->handle()
#4 ./public/index.php(71): Symfony\Component\HttpKernel\Kernel->handle()
#5 {main}

Relevant log output

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

GLPI version: 11.0.8
GLPI path: /var/www/glpi
Installation mode: DOCKER
Current language: fr_FR
Source integrity: OK
Plugin path: /var/glpi/marketplace/datainjection

Anything else?

No response

[ajol99]

I hit the exact same error after upgrading from 2.15.8 to 2.15.9 (GLPI 11.0.8, PHP 8.2.31). Confirmed the root cause and a working local fix, in case it helps get this prioritized.

Root cause: Safe\unserialize() has never existed in thecodingmachine/safe. It's intentionally excluded from that library, since a false return value from unserialize() can't be reliably distinguished from a legitimately deserialized false. I checked the installed thecodingmachine/safe v3.3.0 in GLPI core's vendor/ directory — there is no unserialize() function defined anywhere in generated/8.1/ through generated/8.5/. So the use function Safe\unserialize; import in this plugin can never resolve, on any GLPI/PHP version.

Also worth noting: the plugin's own composer.json doesn't declare thecodingmachine/safe as a dependency at all — it only requires php: >=8.2. So this import was presumably added assuming the function would be available via GLPI core's autoloader, without verifying it actually exists in that library.

Affected files — the same broken import (use function Safe\unserialize;) appears in 6 files, not just front/clientinjection.form.php:

ajax/injection.php
ajax/results.php
front/clientinjection.form.php
inc/clientinjection.class.php
inc/mapping.class.php
inc/model.class.php

Local workaround (tested and confirmed working — the fatal error disappeared and imports process normally again):

First find where the plugin is actually installed on your server — the path varies depending on your GLPI version and how the plugin was installed. Common locations:
<glpi_root>/marketplace/datainjection/ (GLPI 11.x, plugins installed via the Marketplace)
<glpi_root>/plugins/datainjection/ (older / manual installations)
If you're not sure, you can find it with:

   find /var/www -maxdepth 4 -type d -iname "datainjection" 2>/dev/null

(adjust /var/www if GLPI is installed somewhere else)

Once you have the full path, use it explicitly in the commands below — do not run these from a random directory, always use the absolute path you found in step 1. Example (replace the path with yours):

   PLUGIN_DIR="/var/www/html/glpi/marketplace/datainjection"

   # optional but recommended: back up the affected files first
   grep -rl "use function Safe\\\\unserialize" "$PLUGIN_DIR" | \
     xargs -I{} cp {} {}.bak

   # find which files are affected (sanity check, should list the 6 files above)
   grep -rl "use function Safe\\\\unserialize" "$PLUGIN_DIR"

   # apply the fix: remove the broken import from all affected files
   grep -rl "use function Safe\\\\unserialize" "$PLUGIN_DIR" | \
     xargs sed -i '/use function Safe\\unserialize;/d'

   # verify nothing is left
   grep -rln "use function Safe\\\\unserialize" "$PLUGIN_DIR"

The last command should print nothing if the fix applied correctly.

Run the commands as the user who owns the plugin files (often root via sudo, or the same user your web server runs as), so file permissions aren't changed unexpectedly.

After this, unserialize() calls in these 6 files fall back to PHP's native, always-available \unserialize() — no other behavior changes, since the plugin only uses it to deserialize its own session data (not untrusted user input). The injection engine then runs correctly (confirmed via PluginDatainjectionEngine::injectLine() / processBatch() completing without the fatal error in php-errors.log).

Note: this is a workaround, not a permanent fix — it will be overwritten the next time the plugin is updated, until this is fixed upstream. Re-check after every update.

Happy to open a PR with this fix if useful — figured I'd post it here first in case there's a preferred approach (e.g. replacing with an explicit unserialize() + manual error handling instead of just dropping the Safe import, to keep with the project's "safe functions" convention).