Since the update to Nagios XI 2026R1.5, it seems that free variables that contain a $ sign are not longer correctly replaced.
Example:
a host has this variable: _wmi_msas_name with value MSOLAP$HVWNLSQLTST
a service uses this as follows: check_ncpa.py ... -M 'windowscounters/$_HOSTWMI_MSAS_NAME$:Memory/Memory Usage KB'
In Nagios XI 2026R1.4, the windows counter was correct, in Nagios XI 2026R1.5, the $ sign is removed from the counter.
I tried to escape it ($$, /$) but no success.
Any ideas?
$ sign in free variables
Re: $ sign in free variables
@nagios-retail,
Custom variable macros are now being stripped of dangerous characters due to security concerns. In /usr/local/nagios/etc/nagios.cfg, there is the illegal_macro_output_chars config option, which determines which characters are stripped from macros. If you want to use a $ sign in custom variable macros, edit the default option from `~$&|'"<> to `~&|'"<> and restart Core.
I'm sorry for any inconvenience this update may have caused and please let me know if you have any other questions.
- Emmett
Custom variable macros are now being stripped of dangerous characters due to security concerns. In /usr/local/nagios/etc/nagios.cfg, there is the illegal_macro_output_chars config option, which determines which characters are stripped from macros. If you want to use a $ sign in custom variable macros, edit the default option from `~$&|'"<> to `~&|'"<> and restart Core.
I'm sorry for any inconvenience this update may have caused and please let me know if you have any other questions.
- Emmett
Re: $ sign in free variables
Its probably best to not use unix reserved characters.
-
angelapick
- Posts: 1
- Joined: Mon Dec 29, 2025 3:59 am
- Contact:
Re: $ sign in free variables
Is it a regression in XI 2026R1.5's macro expansion?
-
nikolasalexander1
- Posts: 2
- Joined: Sat Jul 04, 2026 1:03 am
Re: $ sign in free variables
Thanks for the detailed explanation, Emmett. This makes sense now.
I was running into the same issue after updating to 2026R1.5. The $ variables in my custom macros were getting stripped out too. Initially thought it was a plugin compatibility issue, but after checking the config file as you mentioned, the illegal_macro_output_chars setting was indeed set to remove special characters.
Changing it from ~$!^& to ~!^& (removing the $) worked for me. However, I'm using some third-party monitoring scripts that rely on these $ variables heavily.
Quick question: Has anyone here found a workaround without having to modify all the legacy macros? Or is updating the macro syntax the only clean solution in this version?
Great catch on the security change though — makes sense they'd tighten that up.
I was running into the same issue after updating to 2026R1.5. The $ variables in my custom macros were getting stripped out too. Initially thought it was a plugin compatibility issue, but after checking the config file as you mentioned, the illegal_macro_output_chars setting was indeed set to remove special characters.
Changing it from ~$!^& to ~!^& (removing the $) worked for me. However, I'm using some third-party monitoring scripts that rely on these $ variables heavily.
Quick question: Has anyone here found a workaround without having to modify all the legacy macros? Or is updating the macro syntax the only clean solution in this version?
Great catch on the security change though — makes sense they'd tighten that up.