by Joe Harris, Sage X3 Technical Team Lead, Net at Work

A recently disclosed MongoDB vulnerability (CVE-2025-14847), informally known as “MongoBleed,” impacts nearly all Sage X3 environments. The issue involves a specific MongoDB compression method that may allow an unauthorized client to access memory, and it has been actively exploited in the wild. While the risk is reduced for deployments where MongoDB is protected behind an internal firewall, it is not fully eliminated.  

To address this vulnerability, MongoDB recommends using alternative compression protocols or disabling compression entirely as a workaround. Sage has released hotfix update editions of MongoDB for versions 4, 7, and 8, covering multiple patch levels of Sage X3 V12. For customers who choose not to apply the hotfix—or for earlier Sage X3 versions where no hotfix will be released—Sage recommends updating the MongoDB configuration to disable the affected compression method. Net at Work has tested and validated this mitigation when implemented using the procedures outlined below. 

Please note that applying this configuration change requires restarting both the Syracuse and MongoDB components of Sage X3. This work should only be performed during a planned maintenance window when all users are logged out of the system. 

Part 1: Changes to the mongodb.conf file 

  1. Locate the file named “mongodb.conf” with your X3 instance’s MongoDB installation folder. It will be located in a subfolder named “config” 
    1. Example: Sage\MongoDBComponent\config 
    2. Different releases of the MongoDB component over the years have had different default naming conventions for the component folder. “MongoDBComponent” is the current standard and has been used consistently for the last several years and is the most common variant. If your X3 instance is older, your MongoDB folder may be named something like “MongoDB” or “SafeX3MongoDB” but it should still have a subfolder named “config” and a file named “mongodb.conf”.

  2.  Copy the file, naming the copy something like “mongodb_original.conf” to save as a backup in case you need to revert to the unmodified version

    1.  It is imperative that this backup be made before any alterations to the file take place. Any issue with the syntax and layout of the config file will cause MongoDB to not restart successfully. If you are unable to restart the MongoDB service and no solution to the issue can be found, rename this backup as “mongodb.conf” to bring the MongoDB service back online. 
  3. A successful update of this file will require an advanced text editor such as Notepad++. Sage and Net At Work recommend Notepad++ for its wide-ranging utility and typically install it on every X3 server as part of a standard deployment. If you do not have it installed on your MongoDB server, it can be downloaded for free from the publisher here. 
    1. Any other text editor that can display space, tab, and end of line symbols can be used instead if that is preferred, though the rest of these instructions assume use of Notepad++. It is NOT recommended to use standard Microsoft Notepad for this change, as it lacks functionality to validate space and tab formatting. 
  4. Open the “mongodb.conf” file in Notepad++ 
    1. It should look similar to this, with file paths and folder names specific to your instance:

  5.  On the upper tool bar, select View – Show Symbol – Show Space and Tab and View – Show Symbol – Show End of Line

  6.  Once these two views have been selected, your file should appear like the following:

    1.  You should see yellow dots denoting spaces, and the “LF” symbol at the end of each line 
      1. Some older versions of Notepad++ only allow you to select one additional symbol view or the other. If your version only allows this, download and install the latest version of Notepad++ and use it. Both character views need to be seen simultaneously 
  7. Within the section of the file headed as “net:” and below the line containing “ipv6: false” and above the line containing “tls:” add an additional line.
     

    1.  NOTE: The new line has been added with a TAB rather than spaces. That’s what the yellow arrow symbol in the screenshot above indicates. The tab now needs to be removed, and spaces added in its place:

  8.  Add the following on this line, without the quotation marks, but with the colon: 
    1. “Compression:”  
      1. The beginning of this entry should align precisely with the lines above and below it:

  9.  Add another line below “compression:” and above “tls:” 
    1. Repeat step 7 to remove the tab character and replace with spaces. This line should contain additional spaces so that it aligns with the lines below “tls:” such as “mode:” and “CAFile:”

  10.   Add the following text, without the quotation marks but including the colon 
    1. “Compressors:”

  11. Add the following text, depending on preference and situation, following “compressors:” and a single space (without quotation marks) 
    1. “Disabled” 
      1. Use this to disable all compression by MongoDB. This is Sage’s suggestion for all instances, and Net At Work’s recommendation if your MongoDB instance is on the same server as your Syracuse webhost component, and no other Syracuse webhosts are part of the solution
         
      2. “snappy,zstd” 
        1. Use this to allow MongoDB to continue to use the Snappy and ZSTD compression methods, while disabling the ZLIB compression method, which is the one affected by the security vulnerability 
        2. This allows MongoDB to continue using data compression, which it typically uses when communicating across the local network to remote Syracuse instances. Use this method if you wish to continue allowing MongoDB to use compression methods unaffected by the announced vulnerability 
      3. “snappy” 
        1. Some older versions of MongoDB and X3, such as X3 V11, do not include the ZSTD compression method and can only use the Snappy method. Use this and omit the “,zstd” if you are on X3 V11 or older and wish to continue to use data compression in MongoDB

  12.   Verify that the correct spacing, alignment, and line returns are in place so that it matches the example screenshots exactly. Misaligned spacing, incorrect positioning, or the presence of tabs instead of spaces will prevent MongoDB from running 
  13. Save the updated file 
    1. Note that the updated configuration will only go into effect once the MongoDB service has been restarted. It does not go into effect immediately. 

Part 2: Shutdown of X3 and Components

  1. The following procedure is for how to perform a clean shutdown of X3. This should be done prior to restarting MongoDB to pick up the modifications to the config file to mitigate the vulnerability. If you are already familiar with this process, you can skip to section three. 
  2. Log into X3 and access your Production folder. 
  3. Use the compass icon above to get to the X3 Menu 
  4. Navigate to Usage>Batch Server > Accounting tasks

  5. Click the Deactivate button

     

    1.  Use “X”  the  button to back out of the Accounting task screen 
  6. Navigate to Administration > Endpoints > Batch server

  7.  Click on the 3 vertical dots and select “Stop All” to stop the batch server

  8.  Stop WEB Pool Services
     

    1.  X3 -> Administration -> Administration -> Web services -> Classic SOAP pools Configuration 
    2. Select the triple dots on each of the listed pools that have the \/ icon (indicating that they are running) next to Alias and click Stop
       

      1.  Click the Trashcan icon on each of the notification windows once each has confirmed stopped to clear the message from your screen. 
  9. Connect to the Windows desktop of your Syracuse server (or servers) 
  10. Open Services.msc 
  11. Stop the Syracuse service 
    1. For versions of X3 prior to V12 P36, there are two services, one named “Safe X3 Agent Syracuse Server NODEx” and one named “Safe X3 Syracuse Server NODEx” 
      1. The “x” in the names above represent a number, usually 0 but sometimes 1, 2, 3, 4, etc.

    2.  Stop the service named “Safe X3 Agent Syracuse Server NODEx” 
    3. This service controls the “Safe X3 Syracuse Server NODEx” service as well – stopping the Agent service will also stop the NODEx service. 
    4. If this service hangs up during the stop procedure, open Task Manager, go to the Details tab, select each instance of the “node.exe” process, and click End Task

      1.  ONLY perform step 2 above if the two Syracuse services do not successfully stop on their own 
    5. For versions of X3 after V12 P36, there is only one service named “Safe X3 Syracuse Server NODEx” 
      1. The same procedure as above can be performed while stopping only this service 
  12. If you have multiple Syracuse host instances in your X3 solution, repeat step 23 on all servers prior to proceeding with shutdown of MongoDB 
    1. If you also have a “Sage X3 Services” instance, stop this as well before proceeding 

Part 3: Stop and Restart of MongoDB Service

  1. Once all Syracuse and associated processes have been stopped on all servers, it is safe to restart MongoDB. 
    1. Stop the service named “Safe X3 MongoDB MONGOxx”

  2.  Start the Safe X3 MongoDB MONGOxx service 
    1. If you get an error when attempting to restart this service, it is likely that there is a configuration, layout, or bad character in your revised “mongodb.conf” file 
    2. Re-verify the changes made in section I above 
    3. If you are still unable to restart MongoDB, change the name of your revised “mongodb.conf” to something like “mongodb_new1.conf” and rename the backup copy created in step 1 as “mongodb.conf” 
      1. This will rollback the config change made and will not mitigate the vulnerability, but it will make X3 functional again. 
  3. Once the Safe X3 MongoDB MONGOxx service is running again, you can restart all Syracuse services on all servers 
    1. Also restart Sage X3 Services if present after all Syracuse services have been restarted 
  4. Once Syracuse has restarted successfully, log back into X3. 
    1. Check that the batch server and all SOAP pools that are set on Auto Start have started running again. They are supposed to after a Syracuse restart. 
    2. If they did not, click the three dots as in section II above next to their names and click “Start”

    3.  Go back into Usage > Batch Server > Accounting tasks  
    4. Click the Accounting task button

    5. Click the Activate button

    6.  Use “X” the  button to back out of the Accounting task screen 

Upon completion of these steps, your Sage X3 environment should be successfully mitigated against the MongoBleed vulnerability. If you encounter any issues, we recommend reviewing each step carefully to confirm configuration accuracy. Should you require assistance at any point, the Net at Work Sage X3 technical team is available to support you.