Below is the list of blog posts with the “NXLog Agent” tag.

We are committed to the security of our customers, and wish to inform you of CVE-2025-67900, a recently published vulnerability affecting the Windows version of NXLog Agent 6.10 and older. Technical description The Windows version of NXLog Agent 6.10.10368 and older includes a Privilege Escalation vulnerability because it attempts to load an OpenSSL configuration file from the hardcoded and unintended directory C:\nxlog4\x64\ on startup. This is a legacy installation directory that may not exist in clean NXLog Agent installations.

In my early days as a Junior Sysadmin, I learned the value of automation when tasked with configuring hundreds of Windows XP machines. Yes, there was a version of Windows called XP. Automating large and repetitive tasks saves time and ensures scalability and consistency in IT environments. Scalability has become very important in IT, and in the golden age of automation tools and APIs, what could be a better way to execute the mass deployment and configuration of your log collection tool than using these very mature and available technologies?

Automatic updates are recommended by many vendors as they are considered essential for safeguarding against security threats and maintaining system performance. Updates not only enhance security but also deliver bug fixes and new features, contributing to improved user experience. Software updates, however, come with the inherent risk of breaking existing functionality and can potentially interfere with other software or the operating system itself causing unintended side effects. Automatic updates that the user has no control over escalate the risk further.

I always wondered what happens to our software when a company purchases it. Okay, I know they will install it and use it. But where do they install it? On what kind of machines? In what kind of environment? And why is it important for them to collect and handle logs? The possibilities are endless. We have customers worldwide; from shoemakers to telecom companies, NXLog is everywhere. But where are the most remarkable places NXLog Agent is employed?

Understanding how NXLog Agent allocates memory is essential to optimize your configuration for performance and utilize system resources efficiently. NXLog Agent is designed for high-performance log collection and processing and is optimized to use system resources efficiently. However, various external factors affect how NXLog Agent uses system resources, including memory, which can impact NXLog Agent’s and its host’s performance. Misconfiguration is the leading factor we see when troubleshooting excessive memory consumption.

There are several reasons you might want to start a particular NXLog module with a delay. You can think of it like delaying the start of a Windows service. In most cases, you need to do this for performance reasons. But there might be other scenarios where you would want to do this, such as collecting logs during a specific time frame. If you have, for example, a less critical module block, you can prioritize the more important one by delaying the less important one.

This post is the first in a series of answers to questions that our customers asked. Clarifying EPS EPS stands for Events Per Second and is considered a standard for measuring the speed of event processing. More precisely, it tells how many events can flow through a particular system in a second. In our case, the number relates to how many events NXLog receives, handles, and outputs in one second.

If you are reading this, then it is safe to say that you are now part of the NXLog community. In other words, you are ready to dive into the world of log collection. Excellent. You have made a great choice. However, before you start collecting logs you should know just how your NXLog log collection tool works. The NXLog log collection tool uses loadable modules that are invoked within the input, data modification, and output stages.