| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Use after free in Microsoft Office Outlook allows an unauthorized attacker to execute code locally. |
| Microsoft Outlook Remote Code Execution Vulnerability |
| Microsoft Outlook Spoofing Vulnerability |
| Microsoft Outlook Remote Code Execution Vulnerability |
| Microsoft Outlook Spoofing Vulnerability |
| Manually dragging and dropping an Outlook email message into the browser will trigger a page navigation when the message's mail columns are incorrectly interpreted as a URL. *Note: this issue only affects Windows operating systems with Outlook installed. Other operating systems are not affected.*. This vulnerability affects Firefox ESR < 60.2 and Firefox < 62. |
| The HCL Traveler for Microsoft Outlook executable (HTMO.exe) is being flagged as potentially Malicious Software or an Unrecognized Application. |
| Microsoft Outlook Information Disclosure Vulnerability |
| HCL Traveler for Microsoft Outlook (HTMO) is susceptible to a control flow vulnerability. The application does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways. |
| HCL Traveler for Microsoft Outlook (HTMO) is susceptible to a DLL hijacking vulnerability which could allow an attacker to modify or replace the application with malicious content. |
| HCL Traveler for Microsoft Outlook (HTMO) is susceptible to a COM hijacking vulnerability which could allow an attacker to modify or replace the application with malicious content. |
| HCL Traveler for Microsoft Outlook (HTMO) is susceptible to a credential leakage which could allow an attacker to access other computers or applications. |
| Microsoft Outlook Remote Code Execution Vulnerability |
| Microsoft Outlook Security Feature Bypass Vulnerability |
| Microsoft Outlook Elevation of Privilege Vulnerability |
| Microsoft Outlook 2010 SP2, Outlook 2013 SP1 and RT SP1, and Outlook 2016 allow an attacker to execute arbitrary commands, due to how Microsoft Office handles objects in memory, aka "Microsoft Outlook Security Feature Bypass Vulnerability." |
| An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability [CWE-22] in Fortinet FortiDLP Agent's Outlookproxy plugin for Windows 11.5.1 and 11.4.2 through 11.4.6 and 11.3.2 through 11.3.4 and 11.2.0 through 11.2.3 and 11.1.1 through 11.1.2 and 11.0.1 and 10.5.1 and 10.4.0, and 10.3.1 may allow an authenticated attacker to escalate their privilege to LocalService via sending a crafted request to a local listening port. |
| An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability [CWE-22] in Fortinet FortiDLP Agent's Outlookproxy plugin for MacOS 11.5.1 and 11.4.2 through 11.4.6 and 11.3.2 through 11.3.4 and 11.2.0 through 11.2.3 and 11.1.1 through 11.1.2 and 11.0.1 and 10.5.1 and 10.4.0, and 10.3.1 may allow an authenticated attacker to escalate their privilege to Root via sending a crafted request to a local listening port. |
| An Exposure of Private Personal Information ('Privacy Violation') vulnerability [CWE-359] in Fortinet FortiDLP Agent's Outlookproxy plugin for MacOS and Windows 11.5.1 and 11.4.2 through 11.4.6 and 11.3.2 through 11.3.4 and 11.2.0 through 11.2.3 and 11.1.1. through 11.1.2 and 11.0.1 and 10.5.1 and 10.4.0, and 10.3.1 may allow an authenticated administrator to collect current user's email information. |
| In the Linux kernel, the following vulnerability has been resolved:
driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction
Mounting NFS rootfs was timing out when deferred_probe_timeout was
non-zero [1]. This was because ip_auto_config() initcall times out
waiting for the network interfaces to show up when
deferred_probe_timeout was non-zero. While ip_auto_config() calls
wait_for_device_probe() to make sure any currently running deferred
probe work or asynchronous probe finishes, that wasn't sufficient to
account for devices being deferred until deferred_probe_timeout.
Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits
until the deferred_probe_timeout fires") tried to fix that by making
sure wait_for_device_probe() waits for deferred_probe_timeout to expire
before returning.
However, if wait_for_device_probe() is called from the kernel_init()
context:
- Before deferred_probe_initcall() [2], it causes the boot process to
hang due to a deadlock.
- After deferred_probe_initcall() [3], it blocks kernel_init() from
continuing till deferred_probe_timeout expires and beats the point of
deferred_probe_timeout that's trying to wait for userspace to load
modules.
Neither of this is good. So revert the changes to
wait_for_device_probe().
[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/
[2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/
[3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/ |
