CVE Database

ASNA Assist and ASNA Registrar before 2025-03-31 allow deserialization attacks against .NET remoting. These are Windows system services that support license key management and deprecated Windows network authentication. The services are implemented with .NET remoting and can be exploited via well-known deserialization techniques inherent in the technology. Because the services run with SYSTEM-level rights, exploits can be crafted to achieve escalation of privilege and arbitrary code execution. This affects DataGate for SQL Server 17.0.36.0 and 16.0.89.0, DataGate Component Suite 17.0.36.0 and 16.0.89.0, DataGate Monitor 17.0.26.0 and 16.0.65.0, DataGate WebPak 17.0.37.0 and 16.0.90.0, Monarch for .NET 11.4.50.0 and 10.0.62.0, Encore RPG 4.1.36.0, Visual RPG .NET FW 17.0.37.0 and 16.0.90.0, Visual RPG .NET FW Windows Deployment 17.0.36.0 and 16.0.89.0, WingsRPG 11.0.38.0 and 10.0.95.0, Mobile RPG 11.0.35.0 and 10.0.94.0, Monarch Framework for .NET FW 11.0.36.0 and 10.0.89.0, Browser Terminal 17.0.37.0 and 16.0.90.0, Visual RPG Classic 5.2.7.0 and 5.1.17.0, Visual RPG Deployment 5.2.7.0 and 5.1.17.0, and DataGate Studio 17.0.38.0 and 16.0.104.0.

In Plesk Obsidian 18.0.69, unauthenticated requests to /login_up.php can reveal an AWS accessKeyId, secretAccessKey, region, and endpoint.

n8n is a workflow automation platform. Prior to version 1.99.0, there is a denial of Service vulnerability in /rest/binary-data endpoint when processing empty filesystem URIs (filesystem:// or filesystem-v2://). This allows authenticated attackers to cause service unavailability through malformed filesystem URI requests, effecting the /rest/binary-data endpoint and n8n.cloud instances (confirmed HTTP/2 524 timeout responses). Attackers can exploit this by sending GET requests with empty filesystem URIs (filesystem:// or filesystem-v2://) to the /rest/binary-data endpoint, causing resource exhaustion and service disruption. This issue has been patched in version 1.99.0.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in PublishPress Gutenberg Blocks advanced-gutenberg allows Stored XSS.This issue affects Gutenberg Blocks: from n/a through <= 3.3.1.

Missing Authorization vulnerability in Melapress Melapress File Monitor website-file-changes-monitor allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Melapress File Monitor: from n/a through < 2.2.0.

Multiple plugins for WordPress are vulnerable to Stored Cross-Site Scripting via the plugin's bundled ThickBox JavaScript library (version 3.1) in various versions due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Multiple plugins for WordPress are vulnerable to Stored Cross-Site Scripting via the plugin's bundled prettyPhoto library (version 3.1.6) in various versions due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The VNC application stores its passwords encrypted within the registry but uses DES for encryption. As DES is broken, the original passwords can be recovered.

The VNC authentication mechanism bases on a challenge-response system where both server and client use the same password for encryption. The challenge is sent from the server to the client, is encrypted by the client and sent back. The server does the same encryption locally and if the responses match it is prooven that the client knows the correct password. Since all VNC communication is unencrypted, an attacker can obtain the challenge and response and try to derive the password from this information.

All communication between the VNC server and client(s) is unencrypted. This allows an attacker to intercept the traffic and obtain sensitive data.

The web application is vulnerable to clickjacking attacks. The site can be embedded into another frame, allowing an attacker to trick a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects.

The application is vulnerable to cross-site request forgery. An attacker can trick a valid, logged in user into submitting a web request that they did not intend. The request uses the victim's browser's saved authorization to execute the request.

The HttpOnly flag is set to false on the PHPSESSION cookie. Therefore, the cookie can be accessed by other sources such as JavaScript.

The configuration of the Apache httpd webserver which serves the MEAC300-FNADE4 web application, is partly insecure. There are modules activated that are not required for the operation of the FNADE4 web application. The functionality of the some modules pose a risk to the webserver which enable dircetory listing.

For failed login attempts, the application returns different error messages depending on whether the login failed due to an incorrect password or a non-existing username. This allows an attacker to guess usernames until they find an existing one.

The Secure attribute is missing on multiple cookies provided by the MEAC300-FNADE4. An attacker can trick a user to establish an unencrypted HTTP connection to the server and intercept the request containing the PHPSESSID cookie.

The web application is susceptible to cross-site-scripting attacks. An attacker who can create new dashboards can inject JavaScript code into the dashboard name which will be executed when the website is loaded.

Multiple services of the DUT as well as different scopes of the same service reuse the same credentials.

Several credentials for the local PostgreSQL database are stored in plain text (partially base64 encoded).

Multiple plugins for WordPress are vulnerable to Stored Cross-Site Scripting via the plugin's bundled Magnific Popups library (version 1.1.0) in various versions due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. NOTE: This vulnerability was fixed in the upstream library (Magnific Popups version 1.2.0) by disabling the loading of HTML within certain fields by default.

In the Linux kernel, the following vulnerability has been resolved: power: supply: max77705: Fix workqueue error handling in probe The create_singlethread_workqueue() doesn't return error pointers, it returns NULL. Also cleanup the workqueue on the error paths.

In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Discard stale CPU state when handling SME traps The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ]

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: handle hdr_first_de() return value The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently. Additionally, error handling for the return value already exists at other points where this function is called. Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sbi->total_valid_block_count syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94 The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.

In the Linux kernel, the following vulnerability has been resolved: clk: bcm: rpi: Add NULL check in raspberrypi_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: fix XQE dma address error The dma addresses of EQE and AEQE are wrong after migration and results in guest kernel-mode encryption services failure. Comparing the definition of hardware registers, we found that there was an error when the data read from the register was combined into an address. Therefore, the address combination sequence needs to be corrected. Even after fixing the above problem, we still have an issue where the Guest from an old kernel can get migrated to new kernel and may result in wrong data. In order to ensure that the address is correct after migration, if an old magic number is detected, the dma address needs to be updated.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init()

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init().

In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work The cited commit fixed a crash when cma_netevent_callback was called for a cma_id while work on that id from a previous call had not yet started. The work item was re-initialized in the second call, which corrupted the work item currently in the work queue. However, it left a problem when queue_work fails (because the item is still pending in the work queue from a previous call). In this case, cma_id_put (which is called in the work handler) is therefore not called. This results in a userspace process hang (zombie process). Fix this by calling cma_id_put() if queue_work fails.

In the Linux kernel, the following vulnerability has been resolved: net: phy: clear phydev->devlink when the link is deleted There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted.