• Vulnerability: XSS, Code Execution, DOS, Password Leak, Weak Authentication, Misc
  • Affected Software: GetSimple CMS
  • Affected Version: 3.3.5 (probably also prior versions)
  • Partially Patched Version: 3.3.6
  • Risk: Medium-High
  • Vendor Contacted: 2015-06-14
  • Vendor Partial Fix: 2015-07-14
  • Public Disclosure: 2015-07-15

GetSimple CMS is a content management system written in PHP. It does not use a database, but xml files instead.

There are various vulnerabilities in version 3.3.5, most of which are fixed in version 3.3.6.

For version 3.3.6 it is important that the htaccess file of GetSimple CMS can be read by the server, as otherwise passwords and other sensitive information will be disclosed (the functionality of the website itself is not affected by an unread htaccess file, so it might go unnoticed).

Password Leak (only partially fixed 3.3.6)


Medium-High; Passwords may leak, depending on Server configuration


A lot of sensitive information is stored in .xml files inside the web root. The .htaccess file of GetSimpleCMS does prevent access to .xml files, but if the htaccess file is not used – for example because AllowOverride None is set (eg for performance or security reasons) – these files become readable. There is no warning in the admin area for when this is happening.

Additionally, backups of these files may be stored with the extension .bak, access to which is not denied by the .htaccess file.

The mentioned files can for example be found at the following locations:


Other xml files contain further sensitive information.


Securing xml files like these is not so easy. An alternative would be to store users in PHP files (properly escaped, as otherwise creating new users might lead to code execution).

If doing it with xml files, it might be a good idea to check if the files are readable from the outside, and if they are, display a large warning.

[I have seen the recommendation in the documentation that admin/health-check.php should be visited. But I would assume that most users do not do that, and its report does not indicate a security problem; it shows eg “0777 Writable – OK” in green; passwords should really be stored securely by default]

Notes on Vendor Fix

The vendor now also forbids access to .bak files. Other than that, this issue was not fixed by the vendor, as it is not an issue if the user has configured the webserver in a specific way.

Because of this, it is extremely important that AllowOverride None is set in the configuration of Apache.


Medium; Authentication bypass, depending on Server configuration


The cookie used to authenticate does not contain truly random data, and never changes. It does contain:

  • $USR (user name)
  • $SALT (per default a value readable in http://localhost/GetSimpleCMS-3.3.5/data/other/authorization.xml, otherwise the global GSUSECUSTOMSALT which is known to other users)
  • $cookie_name (contains the site name and the site version, none of which should be sensitive information, and can be easily found in various files)

It is relatively easy for an attacker to guess all of these values, which would enable them to log in as any user.


Use sessions instead of cookies, or use random data for cookies (stored securely).

Insufficient CSRF Protection (not fixed in 3.3.6)


Low-Medium; CSRF protection can be bypassed by attacker, depending on Server configuration


The CSRF nonce does not contain truly random data and can thus be guessed by an attacker. It does contain:

  • $action (known to attacker)
  • $file (known to attacker)
  • $SALT (site salt, see above)
  • $uid (user agent)
  • $time (two hour window)
  • $USR (user name)

$time is not a problem. If an attacker wants to, they can automatically update it in their attack code. This leaves the user agent. There are a lot of lists with the most common user agents available, and they cover a high percentage of used user agents, so this value can also relatively easily be guessed by an attacker.


Use truly random data for CSRF token, stored in the session.

Code Execution (Admin)

### Risk

Medium; An admin can execute arbitrary PHP code without using the designated theme editor (this is bad because some users might disable the theme editor for security reasons)


  1. A valid image file with PHP code inside is needed (can eg be created by creating a 1×1 png via gimp, and editing “created by gimp” in vim to be <?php passthru($_GET['c']); ?>)
  2. Upload image
  3. rename file extensions: http://localhost/GetSimpleCMS-3.3.5/admin/inc/thumb.php?src=evil.png&dest=evil.php


    Check file extension when renaming.

    DOS (via CSRF)


    Medium; Relevant System files can be destroyed by an admin or by an attacker if admin visits their website


    Any file on the system that the web user has access to can be overwritten with an image file that already exists on the server. Credentials are required, but the request is not protected by CSRF protection.




    1. Replace current insufficient directory traversal protection (filtering out ../) with proper protection (eg filepath_is_safe)
    2. Check if dest already exists, if so, don’t overwrite it
    3. Add CSRF protection to thumb.php



    Medium; arbitrary JavaScript execution, which can lead to cookie stealing, key logging, and CSRF protection bypass, which in this case leads to arbitrary code execution via eg the theme editor


    http://localhost/GetSimpleCMS-3.3.5/admin/filebrowser.php?returnid=foobar&func=foobar %3D%3D 'function') {}}}alert(1); </script>


        <script type='text/javascript'>
        function submitLink($funcNum, $url) {
                if (isset($_GET['func'])){
                $func = @$_GET['func'];
                        if(typeof window.opener.<?php echo $func; ?> == 'function') {
                            window.opener.<?php echo $func; ?>('<?php echo $returnid; ?>');


    Create a whitelist of acceptable functions, and check if $func is in it.

    Code Execution (Admin, not with default config)




    Currently, this is the function that validates that no invalid files (such as PHP files) are uploaded:

    function validate_safe_file($file, $name, $mime){
        global $mime_type_blacklist, $file_ext_blacklist, $mime_type_whitelist, $file_ext_whitelist;
        $file_extention = pathinfo($name,PATHINFO_EXTENSION);
        $file_mime_type = $mime;
        if ($mime_type_whitelist && in_arrayi($file_mime_type, $mime_type_whitelist)) {
            return true;   
        } elseif ($file_ext_whitelist && $in_arrayi($file_extention, $file_ext_whitelist)) {
            return true;   
        // skip blackist checks if whitelists exist
        if($mime_type_whitelist || $file_ext_whitelist) return false;
        if (in_arrayi($file_mime_type, $mime_type_blacklist)) {
            return false;  
        } elseif (in_arrayi($file_extention, $file_ext_blacklist)) {
            return false;  
        } else {
            return true;   

    This function works fine with default configuration, because the whitelist is not used. But if a user were to use the whitelist approach (because whitelists are safer than blacklists), this would actually be vulnerable, as it would then rely on the given mime type, which is entirely user controlled.


    Only return true if the mime type as well as the file extention is inside the respective whitelist.

    Directory Traversal


    minimal; it is possible to go up one directory when viewing files




    Add an additional check for “..”, or (prefered) perform the filepath_is_safe check on “tsl($template) . $template_file” right before file_get_contents.


    Insecure Hashing

    sha1 and a global site salt instead of a proper hashing function and per-user salts are not really considered secure enough anymore; It would be good to use bcrypt or similar instead.

    PHP File Edit

    PHP file edit (such as provided by the theme editor) leads to code execution, which significantly increases the damage other vulnerabilities can do. Eg XSS, CSRF, or weak authentication now not only lead to the application being compromised, but to the compromise of everything the web user has access to.

    It might be a good idea to add a configuration field to disable this, so that users who want additional security can have it.


    • 2015-06-14: Requesting Contact Email via official forum
    • 2015-06-15: Vendor Reply
    • 2015-06-15: Send Advisory
    • 2015-06-16: Vendor Confirmation, Issues opened
    • 2015-06-22: Vendor Released Fix as Beta Version
    • 2015-07-13: Disclosure Announced
    • 2015-07-13: Vendor Confirmation
    • 2015-07-14: Vendor Releases Fix
    • 2015-07-15: Disclosure