• [ ] WordPress has a feature called embeds. By including a construction like[embed]<https://example.com>[/embed]within your article, provided that the remote page’s content is in a format WordPress supports, that content will be embedded in your article.

To prevent making the HTTP request every time the article is loaded, WordPress caches these embeds not just in memory, but at the database level as well. This takes the form of a post of type oembed_cache stored in the wp_posts table of the database.

WordPress posts are another supported embed type. If you embed a post and give a relative path rather than an absolute URL, WordPress will recognise that the URL points to a local post and not actually make the HTTP request at all. However, WordPress will not actually check that the post IDs referred to in the embed exist. Thus, placing text like[embed width="500" height="750"]/?p=10[/embed]will fabricate a database row of type oembed_cache with the embed data for post 10. Let’s say that new row ID is 11.

Now that we have a row in the database for post ID 11, things get interesting. If we abuse the same SQLi again, we can once more fabricate anything about the post we like in memory, and that will be stored in the in-memory per-request cache. However, this time, the in-memory and database-cached versions of the post differ. WordPress will recognise this and try to reconcile the two versions:

wp_update_post([
      'ID'           => 11,
      'post_content' => "benign html coming from the embed",
]);

Here, the ID and post_content are set before writing to the database. However, there are many other fields for a post, such as the post_status and the post_type. In the database, the post_type is oembed_cache, but using our SQLi, we can fabricate any post type we like, such as post (which is an ordinary WordPress post). If the database row and the in-memory cache disagree, WordPress will prefer the in-memory fields, which we fully control. Therefore, we can force the oembed_cache rows to become normal posts, suddenly ‘popping’ them into existence. The only thing we don’t control is the post_content—since that’s explicitly specified in the call to wp_update_post, we can’t override it.

==⇒ Tức là ở đây ta có thể đổi bài viết trong database phần post_type thành post được rồi chỉ là ko kiểm soát được cái post_content thôi.