Title: Database integrity checks
Last modified: August 19, 2016

---

# Database integrity checks

 *  [jihymas](https://wordpress.org/support/users/jihymas/)
 * (@jihymas)
 * [17 years, 10 months ago](https://wordpress.org/support/topic/database-integrity-checks/)
 * I have [previously requested Anti-Hacking Checksums](http://wordpress.org/support/topic/196762?replies=4).
 * Now – just to keep everybody busy – I would like to ask for automated database
   integrity checks. The following background has been added to [my blog post on the subject](http://www.prefblog.com/?p=2593):
 * > The database has a table, wp_postmeta, which tracks attachments. One record
   > in this table has the values: meta_id=8474, post_id=2181, meta_key = ‘_wp_attached_file’,
   > meta_value=’/services1/webpages/p/r/prefblog.com
   > /public//../../../../../../../../../../../../../../../../../
   > tmp/10bum.txt’
 * There is also: meta_id=8472, post_id=2180, meta_key = ‘__wp_attached_file’, meta_value
   = ‘/services1/webpages/p/r/prefblog.com
   /public//../../../../../../../../../../../../../../../../../
   tmp/2newbum.txt’
 * These records have been removed.
 * I have also deleted some entries in the wp_posts table. As far as I can make 
   out from the [WordPress codex](http://codex.wordpress.org/Function_Reference/get_post)
   the value of ‘post_parent’ should reference a ‘post_id’ in the same table, which
   are all positive integers.
 * After noting some odd entries, I queried the database: ‘select * from wp_posts
   where post_parent < 0’ and came up with seven records. Two have post_parent set
   to numbers that are large and negative; the ‘guid’ field indicates that this 
   is stuff that I did, in fact, upload but somehow screwed up.
 * The remaining 5 records all have post_parent set to -1, with ‘guid’ having a 
   variety of values: the first one, with ‘post_modifed’ = ‘2008-03-25 05:26:58’
   has ‘guid’ = ‘[http://www.prefblog.com](http://www.prefblog.com)
   //../../../../../../../../../../../../../../../../../
   tmp/3rbsmag.txt’. The other entries are similar, with filenames 10bum.txt (three
   times) and 2newbum.txt.
 * All these records have been deleted. Note that with these long field values, 
   I have added a HTML line-break to make the full field look nice on this post.
 * I note that the first of these highly suspicious entries occurred within a week
   of my WP 2.3.3 installation!
 * It seems to me to be clear that a negative value for post_parent is simply wrong.
   A suite of functions whereby I could automatically validate the database for 
   such things would be very useful.

Viewing 1 replies (of 1 total)

 *  [mrmist](https://wordpress.org/support/users/mrmist/)
 * (@mrmist)
 * [17 years, 10 months ago](https://wordpress.org/support/topic/database-integrity-checks/#post-836433)
 * Suggest it as an enchancement on the tracker.
 * However, I think such things are best as part of an optional plugin. I have no
   interest in checking for data validity when the site is working, and I wouldn’t
   want to sacrifice site performance for the sake of having such checks ran on 
   any kind of regular basis.
 * What you seem to be describing is occurences where your installation has been
   hacked and spurious data inserted. Whilst it’s good to be able to find such things,
   I’m not convinced that it’s best to be doing it from inside the (potentially)
   hacked application.

Viewing 1 replies (of 1 total)

The topic ‘Database integrity checks’ is closed to new replies.

 * In: [Requests and Feedback](https://wordpress.org/support/forum/requests-and-feedback/)
 * 1 reply
 * 2 participants
 * Last reply from: [mrmist](https://wordpress.org/support/users/mrmist/)
 * Last activity: [17 years, 10 months ago](https://wordpress.org/support/topic/database-integrity-checks/#post-836433)
 * Status: not resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics