WiX toolset lets developers create installers for Windows Installer, the Windows installation engine. When a bundle runs as SYSTEM user, Burn uses GetTempPathW which points to an insecure directory C:\Windows\Temp to drop and load multiple binaries. Standard users can hijack the binary before it's loaded in the application resulting in elevation of privileges. This vulnerability is fixed in 3.14.1 and 4.0.5.

A flaw has been discovered in GnuTLS where an application crash can be induced when attempting to verify a specially crafted .pem bundle using the "certtool --verify-chain" command.

Symfony1 is a community fork of symfony 1.4 with DIC, form enhancements, latest Swiftmailer, better performance, composer compatible and PHP 8 support. Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project. This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. Symfony 1 depends on Swift Mailer which is bundled by default in vendor directory in the default installation since 1.3.0. Swift Mailer classes implement some `__destruct()` methods. These methods are called when php destroys the object in memory. However, it is possible to include any object type in `$this->_keys` to make PHP access to another array/object properties than intended by the developer. In particular, it is possible to abuse the array access which is triggered on foreach($this->_keys ...) for any class implementing ArrayAccess interface. This may allow an attacker to execute any PHP command which leads to remote code execution. This issue has been addressed in version 1.5.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.

friendsofsymfony1

The SiteOrigin Widgets Bundle plugin for WordPress is vulnerable to Stored Cross-Site Scripting via several parameters in all versions up to, and including, 1.58.7 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor access or above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Affected parameters include: $instance['fonts']['title_options']['tag'], $headline_tag, $sub_headline_tag, $feature['icon'].

siteorigin

A CWE-1269 “Product Released in Non-Release Configuration” vulnerability in the Django web framework used by the web application (due to the “debug” configuration parameter set to “True”) allows a remote unauthenticated attacker to access critical information and have other unspecified impacts to the confidentiality, integrity, and availability of the application. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-613 “Insufficient Session Expiration” vulnerability in the web application, due to the session cookie “sessionid” lasting two weeks, facilitates session hijacking attacks against victims. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-646 “Reliance on File Name or Extension of Externally-Supplied File” vulnerability in the “iec61850” functionality of the web application allows a remote authenticated attacker to upload any arbitrary type of file into the device. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-425 “Direct Request ('Forced Browsing')” vulnerability in the “measure” functionality of the web application allows a remote unauthenticated attacker to access confidential measure information. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-1236 “Improper Neutralization of Formula Elements in a CSV File” vulnerability in the “file_configuration” functionality of the web application (concerning the function “export_file”) allows a remote authenticated attacker to inject arbitrary formulas inside generated CSV files. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-425 “Direct Request ('Forced Browsing')” vulnerability in the “file_configuration” functionality of the web application allows a remote unauthenticated attacker to access confidential configuration files. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-434 “Unrestricted Upload of File with Dangerous Type” vulnerability in the “file_configuration” functionality of the web application allows a remote authenticated attacker to upload any arbitrary type of file into the device. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-552 “Files or Directories Accessible to External Parties” vulnerability in the embedded Chromium browser allows a physical attacker to arbitrarily download/upload files to/from the file system, with unspecified impacts to the confidentiality, integrity, and availability of the device. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-184 “Incomplete List of Disallowed Inputs” vulnerability in the embedded Chromium browser (concerning the handling of alternative URLs, other than “ http://localhost” ) allows a physical attacker to read arbitrary files on the file system, alter the configuration of the embedded browser, and have other unspecified impacts to the confidentiality, integrity, and availability of the device. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-250 “Execution with Unnecessary Privileges” vulnerability in the embedded Chromium browser (due to the binary being executed with the “--no-sandbox” option and with root privileges) exacerbates the impacts of successful attacks executed against the browser. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-122 “Heap-based Buffer Overflow” vulnerability in the “logger_generic” function of the “Ax_rtu” binary allows a remote authenticated attacker to trigger a memory corruption in the context of the binary. This may result in a Denial-of-Service (DoS) condition, possibly in the execution of arbitrary code with the same privileges of the process (root), or have other unspecified impacts on the device. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

A CWE-798 “Use of Hard-coded Credentials” vulnerability in the MariaDB database of the web application allows a remote unauthenticated attacker to access the database service and all included data with the same privileges of the web application. This issue affects: AiLux imx6 bundle below version imx6_1.0.7-2.

ailux

Directus is a real-time API and App dashboard for managing SQL database content. Prior to version 10.8.3, the exact Directus version number was being shipped in compiled JS bundles which are accessible without authentication. With this information a malicious attacker can trivially look for known vulnerabilities in Directus core or any of its shipped dependencies in that specific running version. The problem has been resolved in versions 10.8.3 and newer.

monospace

The SiteOrigin Widgets Bundle plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the features attribute in all versions up to, and including, 1.58.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor access or higher, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

siteorigin

The SiteOrigin Widgets Bundle plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the onclick parameter in all versions up to, and including, 1.58.3 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers with contributor access or higher to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. 1.58.3 offers a partial fix.

siteorigin

In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix a use after free in ath10k_htc_send_bundle In ath10k_htc_send_bundle, the bundle_skb could be freed by dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later by bundle_skb->len. As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to skb_len after the bundle_skb was freed.

linux

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead. This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.

linux