Description

Newell Brands DYMO ID 1.5.1.71 resolves its plugin Modules directory relative to the process working directory. An attacker could store a job file alongside malicious modules / DLL that sets the process working directory to the job file's folder when a victim clicks on the file, resulting in code execution at the victim's privilege level. Fixed in 1.6.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-10-05T21:16:32.400Z",
  "pubdate": "2026-10-05T21:16:32.400Z",
  "executiveSummary": "Newell Brands DYMO ID version 1.5.1.71 is susceptible to a DLL hijacking vulnerability caused by insecure search path resolution for plugin modules.\nThe vulnerability stems from the application's practice of resolving its plugin Modules directory relative to the current process working directory rather than an absolute, trusted path.\nAn attacker can exploit this by placing a malicious DLL alongside a legitimate job file. When a victim opens this job file, the application inadvertently changes its working directory to the untrusted folder, leading the application to load and execute the attacker's payload.\nSuccessful exploitation results in arbitrary code execution at the privilege level of the victim user.\nThis vulnerability is classified as a local code execution flaw, requiring user interaction to execute the malicious job file.\nThe risk is significant as it allows for potential lateral movement or persistent compromise on affected systems.\nThis issue has been addressed in version 1.6.0; users are strongly encouraged to update to mitigate the risk of exploitation.",
  "technicalDetails": "The vulnerability is rooted in an insecure library loading mechanism utilized by DYMO ID 1.5.1.71. Specifically, the application resolves the path for its plugin Modules directory based on the process working directory, which is highly dynamic and user-controllable.\nIn the Windows environment, when an application is launched to process a specific file, the working directory may be automatically set to the directory containing that file if the application or its shortcut is not explicitly configured to define a static working directory.\nThe exploitation flow begins when an attacker crafts a malicious payload in the form of a DLL that mimics the naming convention of expected plugin modules. This malicious DLL is then bundled with a legitimate DYMO ID job file.\nThe attacker distributes this package to a target user. Upon the victim opening the job file, the application process is initiated, and the working directory is set to the location of the job file.\nBecause the application logic instructs the system to look for plugin modules relative to the now-compromised working directory, the loader searches this untrusted folder first. The application then inadvertently identifies, loads, and executes the malicious DLL present in that folder.\nBecause the execution occurs within the context of the DYMO ID application process, the payload inherits the full permissions of the user who opened the job file.\nThis attack requires local access or social engineering to convince a user to open the manipulated job file from an untrusted location. Once triggered, the malicious code executes immediately without additional authentication or elevated privileges beyond those already held by the victim.\nThis vulnerability is effectively an arbitrary code execution vector. Post-exploitation, an attacker could establish persistence, exfiltrate sensitive data, or install additional malicious tools on the host system."
}