You could try adding the following right at the top of your script. (Even add it before use strict - before everything else except perhaps the #! line.)

BEGIN {
    package Tie::Env::Warn;
    use Carp qw(cluck);
    use Tie::Hash;
    our @ISA = 'Tie::StdHash';
    sub STORE {
        my ($self, $key, $value) = @_;
        cluck "Modification of \$ENV{$key}!";
        $self->SUPER::STORE($key, $value);
    }
    tie %ENV, __PACKAGE__;
};
[download]

That will print out a warning including a stack trace (which shows line numbers, etc) whenever %ENV values are assigned. If that doesn't help, then you could also try hooking the DELETE and CLEAR methods (the example above just hooks STORE).

Thank you. Found the culprit: Date/Manip/TZ.pm version 6.34 line 96. Looks like it's fixed in 6.37 (the latest on CPAN).

Relieved!

Are you sure your script isn't called with modified ENV already? cron-jobs usually start with a modified aka purified ENV

If not you might add debug code that checks ENV and warns about it. If your script is not multithreaded this should enable you to pinpoint the culprit in a few runs with ever narrower "bisection" steps.

perlsec provides information about modifying %ENV (including $ENV{PATH}). As already mentioned by jethro, it's standard practice for cron.

I wouldn't assume something bad or malicious has occurred. Consulting System Administrators is probably your best bet in the first instance.

child process inherit %ENV from parent process, and they can modify it, so their children inherit a totally different %ENV

perl -V ought to list any perl specific customers (like PERLLIB, PERL5OPT ...) that might modify your env

ps ps axjf ought to list any parent procs

I find out that the script to execute a program

I find out that the script fails to execute a program